Morpha

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

With no annotations provided, the description carries the burden of explaining side effects and constraints. It discloses that the asset must already exist, that the overlay is frame-aligned at 30 fps, and that it plays in the preview and is mixed into the MP4 export. It does not mention failure behavior if the asset is missing, but the key behavioral traits are covered.

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 concise and well-structured: a single statement of purpose followed by essential prerequisite and behavior details. Every sentence contributes useful information without redundancy or fluff.

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?

Given the schema covers all parameters and there is no output schema, the description provides sufficient context for an agent to decide when to use the tool, what inputs are needed, and what the observable outcome will be. It could mention return values or error handling, but the core context is present.

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?

The schema already provides 100% coverage of parameters with detailed descriptions, so the added semantic value from the tool description is limited. The description reinforces the overall frame-rate context but does not add meaning beyond the existing parameter descriptions.

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 description clearly identifies the tool's purpose with a specific verb ('Add') and object ('audio overlay'), and the name aligns perfectly. It also distinguishes this tool from siblings like update_audio_overlay and remove_audio_overlay by describing the creation action.

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?

The description provides concrete usage guidance: supported audio formats, the required asset path, and the frame-to-seconds conversion rule. It does not explicitly compare with update_audio_overlay or upload_audio, but the naming and action imply when this should be used for new overlays.

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

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

With no annotations available, the description carries the full burden and does so richly: it discloses the two modes, how line-sync visibility windows work via hold-eased opacity keyframes, that layers are always wrapped in a 'captions' group, and what the call returns. This is exemplary transparency for a creation tool.

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 dense but every sentence earns its place: purpose, mode behavior, style, default placement, grouping behavior, and return value. It front-loads the most important information and avoids filler or repetition.

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?

Given the lack of annotations and output schema, the description supplies the essential behavioral and return context: created text element ids plus groupElementId, the grouping guarantee, and the two modes. The comprehensive input schema covers parameters, so nothing critical for calling this tool correctly is missing.

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 goes beyond the schema by explaining how mode line-sync behaves ('active-line karaoke read'), what the group wrapping means for the layer list, and that the return includes groupElementId. This adds real semantic value on top of the complete 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?

The description opens with a specific verb plus resource: 'Build a caption track from pre-timed lines.' It distinguishes this from related siblings like transcribe_clip (which produces timings) and merge_caption_lines/split_caption_line (which manipulate existing caption lines), while the mode detail further clarifies exactly what is built.

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?

The description clearly signals when to use this tool: after obtaining pre-timed lines, e.g. from transcribe_clip's word timings. It gives clear context but does not explicitly contrast it with merge_caption_lines or split_caption_line, so it lacks explicit when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It usefully discloses overwrite behavior, stop-by-stop crossfade between adjacent keyframes, 30 fps timing, and 0-indexed frames. It could add auth requirements or return behavior, but the key mutation semantics are transparent.

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?

Four short sentences front-load the action and then pack only high-value details: target types, background synonym, Fill value semantics, and timing. There is no filler or redundant explanation.

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 mutation tool with no annotations and no output schema, the description plus fully-documented schema covers everything needed to call it correctly: which elements, how frames are counted, what value shapes are accepted, and overwrite/crossfade behavior. No critical gap is evident.

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 adds general context such as overwrite behavior and crossfade, but most of this is already present in the schema's parameter descriptions. It does not meaningfully clarify any parameter beyond what the schema documents.

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 description opens with 'Add or overwrite a colour keyframe on a fill track', specifying the exact action, resource, and overwrite semantics. It also defines the target scope (leaf elements, background.canvas synonym), which distinguishes it from generic add_keyframe or add_speed_keyframe siblings.

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?

The description clearly implies use for color keyframing on a fill track and clarifies frame indexing, but it never names alternatives such as add_keyframe, add_keyframes, or set_layer_fill, nor states when not to use this tool. Usage context is inferable but not explicit.

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

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

No annotations are present, so the description carries the transparency burden. It explicitly states that the projectId 'selects which existing project this call mutates' and describes the draw action as creating an editable element. There is no contradiction with annotations, and the mutation is clearly indicated.

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 front-loaded with the core action and then summarizes parameter behaviors in a compact format. It repeats some parameter details that already exist in the schema (e.g., color format, stroke_width units), which adds a little redundancy but does not bloat the text.

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?

The description covers the purpose, usage context, and effect of key parameters. It does not mention the return value (e.g., a layer ID) or the precise effect on existing layers, but for a mutation tool without an output schema this is not a critical omission. Overall it gives enough context to use the tool 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 coverage is high (89%), with descriptions for x1/y1/x2/y2, bend, color, projectId, and stroke_width. The description adds meaning by contextualizing bend as a perpendicular offset and providing default behavior for arrow_head. It does not fully describe arrow_head's enum values beyond the default, but the enum is self-explanatory.

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 ('Draw') and resource ('editable arrow / curved line') and clearly explains the bezier/arrowhead nature. It distinguishes itself from other add_* tools by focusing on callout arrows, and the description is unambiguous about its function.

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?

Provides an explicit use case ('Use this for callout arrows') and explains the effect of each optional parameter. However, unlike the high-scoring example, it does not explicitly name alternative tools (e.g., add_shape) or state when not to use it, so a small gap remains.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does well by explicitly stating idempotency ('re-adding an existing entry is a no-op') and normalization behavior ('scheme/port/path stripped'). It omits error and return details, but the core side effects are clearly disclosed.

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 two compact sentences with no filler. It front-loads the primary purpose, then adds idempotency and normalization details in a natural order.

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 simple two-parameter mutation with no output schema, the description plus full parameter documentation is largely sufficient for correct invocation. It covers what the tool does, idempotency, and input normalization. Missing response/error behavior is a minor gap given the tool's simplicity.

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%, with both origin and projectId already well documented. The description adds some normalization context for origin, but this is also present in the schema. It does not add significant meaning beyond 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?

The description states a specific action and resource: 'Add one hostname to the project's embed allowlist.' The word 'one' plus the allowlist context clearly distinguishes this from sibling tools like set_embed_origins or remove_embed_origin.

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?

The description gives clear context for when to use the tool: when adding a single hostname to the project's embed allowlist. It does not explicitly name alternatives or exclusions, but the idempotency note and 'one hostname' phrasing imply the intended use case.

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

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

No annotations exist, so the description carries the full behavioral burden. It discloses copy semantics (self-contained, fresh ids, detached, source changes don't affect the copy), group-children inclusion, byte copying, live editor pickup, and return shape, all beyond what schema provides.

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 dense but efficient description; every clause earns its place. It front-loads the core purpose, then covers usage, prerequisites, runtime behavior, and return value without redundancy.

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 three-parameter operation with no output schema and no annotations, the description is essentially complete. It specifies required inputs, source/destination semantics, prerequisites, behavioral effects, and the return contract, leaving little an agent needs to infer.

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 covers 100% of parameters already, so baseline is 3. The description adds value by explaining the relationship between sourceProjectId and elementId ('from list_collection') and the consequence of those parameters (fresh ids, original position, full detachment). This lifts it slightly above baseline.

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 ('Add'), resource ('item from the user's Collection into a project'), and copy semantics. The direction (from collection to project) clearly distinguishes it from sibling tools like add_to_collection and add_image_layer, so an agent can select it without opening schemas.

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 clear context: it is the tool for copying an existing collection item into a project, with parameters sourced from list_collection. It states prerequisites (element must be in source collection, read access required) but does not explicitly name when to prefer an alternative like add_to_collection, so it stops 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.

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

No annotations are present, so the description carries the burden. It discloses non-obvious operational behavior: the asset must already exist at a specific path, the upload mechanisms, and the fact that reusing a filename creates a new layer with a fresh id rather than overwriting. It does not mention error cases or stacking order, but the main side effects are adequately surfaced.

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?

Three sentences with the primary action front-loaded, followed by the required asset context and the duplication rule. The long second sentence is information-dense and every clause earns its place.

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?

The tool is a mutation with nested optional semantics, but the schema fully documents the parameters and the description covers the non-obvious asset prerequisite and duplication behavior. There is no output schema, so an explicit return-value note would be a minor improvement; otherwise the agent has enough to invoke 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?

The schema already documents all 7 parameters thoroughly (100% coverage). The description adds filename-specific meaning: the asset must be pre-uploaded to a known path, and duplicate layers are created by reusing a filename — details not inferable from the schema alone.

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 "Add an image layer" — a specific verb and resource, and the asset-type scope distinguishes it from sibling tools like add_text_layer, add_video_layer, and add_shape. The duplication note adds a secondary use case without blurring the primary purpose.

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?

Clearly describes the required precondition (asset must already exist), gives specific upload routes, and explains the duplicate-layer path by reusing a filename. It does not explicitly name sibling alternatives, but the context makes it clear when this tool applies.

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

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

With no annotations provided, the description carries the full burden, and it delivers: overwrite behavior, absolute vs offset coordinate semantics, canvas dimensions, group pivot behavior, scale orbit behavior, opacity range, frame rate, and the critical override of static base values. This is exceptionally transparent.

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 dense but every sentence earns its place. It front-loads the purpose and then structures property-specific semantics clearly. There is no fluff or repetition of schema fields.

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 mutation tool with no annotations and no output schema, the description covers most behavioral context needed to call it correctly. It is slightly incomplete because width, height, and curve keyframe semantics are omitted, and sibling routing guidance would improve completeness.

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 already 83%, and the description adds strong meaning for the 'property' and 'value' parameters by explaining coordinate spaces, rotation units, scale behavior, and opacity range. However, it leaves width, height, and curve property semantics unexplained, so it does not fully compensate for those gaps.

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 description clearly names a specific verb and resource: 'Add or overwrite a keyframe on a layer's animation track.' It conveys the core action and scope, but it does not explicitly differentiate itself from close siblings like add_keyframes or set_keyframes_batch.

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?

No guidance is given on when to use this tool versus alternatives such as add_keyframes, set_keyframes_batch, add_color_keyframe, or add_speed_keyframe. The semantics are explained well, but the agent is left to infer the appropriate selection context.

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

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

With no annotations provided, the description carries the full burden and delivers real behavioral context: it reveals that loop mode is applied in the same call, that elementId/property are factored out of the loop body, and that this is a multi-keyframe batched mutation. It does not state whether the call replaces or appends to existing keyframes on the track, which is a minor gap given zero annotation coverage.

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?

Three sentences with zero waste: purpose first, idiomatic context second, exclusion of the sibling alternative third. Every sentence earns its place and the critical scoping constraint is front-loaded.

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 5-parameter tool with no output schema and no annotations, the description is nearly complete: it covers purpose, scope constraints, the fold-in loop behavior, and sibling disambiguation against a very large tool set. The only missing pieces are what the call returns and whether existing track keyframes are replaced or appended — minor given the strength of the disambiguation and operation semantics.

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 80% (only 'property' lacks its own description, though its enum clarifies it), so the schema already documents most parameters. The description adds conceptual framing — that elementId/property scope the call and loop is folded into it — but provides no new format or value semantics beyond 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?

The description opens with a precise verb+resource statement: 'Add many keyframes to ONE element's ONE property in a single call' — the singular scoping (one element, one property) is exactly what distinguishes it from siblings like set_keyframes_batch. It further frames the idiomatic use case (ripple dot pulse, snowflake fall, equaliser-bar wave), leaving no ambiguity about what this tool does.

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?

The description gives explicit when-to-use guidance ('The idiomatic form when every layer in a multi-element animation gets its own track') and names the concrete alternative with the condition that selects it: 'Use set_keyframes_batch instead when you need to mix elements/properties in one atomic call.' It also signals that set_track_loop is folded in, preventing a redundant call.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does so thoroughly. It discloses that the source layers are inlined as a collapsible group, re-keyed to fresh ids, pinned to an immutable version, and that edits are local and never propagate back to the source. It also explains how embedded bands appear in describe_video output, giving the agent a complete picture of side effects.

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 front-loaded with the core action and immediately explains the important constraints. It is longer than one sentence, but every sentence earns its place by covering a distinct operational aspect: what the tool does, how layers are inlined, how pinning works, local-only editing, re-pinning, and detection. There is no filler or redundancy.

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 complex tool with no annotations and no output schema, the description is remarkably complete: it specifies inputs, the embedding semantics, the mutation behavior, and how to identify the result. The only notable gap is that it does not describe the return value or possible failure modes, such as what happens if the source project cannot be resolved, though the schema does cover the self-embedding constraint.

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 100%, so the baseline is 3, but the description adds meaningful interaction semantics: source_morpha_id is explicitly named as the source project id, version is explained as an optional pin label, and the description clarifies that the server resolves and inlines the pinned version. It goes beyond repeating the schema by connecting each parameter to the embedding workflow.

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 description names a specific resource ('another of the user's projects'), a precise action ('Embed'), and the resulting object ('version-pinned band'). It clearly differentiates this from siblings like add_embed_origin and create_project by explaining the cross-project embedding concept. An agent can tell exactly what this tool does without needing to inspect 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?

The description provides clear context for when to use the tool and how to handle the version-pinning workflow. It explicitly tells the agent that re-pinning to a different version should be done from the editor's Inspector, not this tool, and mentions describe_video for identifying embedded bands. It does not explicitly say 'use X instead of Y', but the operational context is strong enough for an agent to decide correctly.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It explains the mutation effects, deep-copy semantics with a fresh id, no page-count limit, the active-page side effect, and the return value. This is rich, specific behavioral transparency for a mutating tool.

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 front-loaded with the core action and then efficiently covers conditional behavior, limits, side effects, and return value. Each sentence carries useful information, and nothing feels redundant or padded.

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?

Given there is no output schema, the description properly states that the new page's index is returned. It also covers the behavior of both parameterized modes, the active-page effect, and the absence of a page-count limit. For a 3-parameter tool with one required parameter, this is complete enough for safe 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 coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: duplicate_index controls whether a blank or deep-copied page is appended, and the blank page is sized to the project's canvas. The name and projectId parameters are adequately 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?

The description leads with a specific verb and resource: 'Append a page to the project.' It further clarifies the operation by explaining the single-to-multi-page transition and highlighting that the new page becomes active, distinguishing this from page-related siblings like delete_page, reorder_pages, and select_page.

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?

The description gives clear usage context through two explicit modes: without duplicate_index a blank page is appended, and with duplicate_index an existing page is deep-copied. It does not explicitly name alternative tools or state when not to use it, but the conditional behavior gives enough guidance for an agent to select the correct invocation.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It adds useful traits: the layer is a native vector shape, and omitted x/y/w/h defaults to canvas center. However, it says nothing about return values, reversibility, or the important default timeline behavior (persistent overlay) that is only described in the block parameter schema.

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 front-loaded with the core action, and the long shape list earns its place by disambiguating the `kind` enum. The image-layer warning and default-position note are compact and add real decision value without padding.

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 an 8-parameter tool with no output schema and no annotations, the description is serviceable but not fully self-contained. An agent still must rely on the block schema to learn that omitting the block creates a persistent overlay and that passing it creates a bounded clip; return/output behavior is also unspecified.

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 38%, so the description needs to compensate, and it does for key params: it explains that `kind` selects a primitive and lists the allowed values, and clarifies that omitted x/y/w/h places the shape at the canvas center. The schema already documents block, color, and projectId, leaving only coordinate units and width/height semantics implicit.

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 description starts with a specific action and resource, 'Add a shape layer,' and enumerates the exact primitive kinds, making the tool's scope clear. It also distinguishes itself from image layers with 'never substitute an image layer for one,' though it doesn't explicitly name sibling alternatives like add_text_layer or add_curve.

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?

The description gives clear context for when to use the tool: for native vector shapes, and explicitly warns against using an image layer instead. It also provides a useful behavioral hint by saying default placement is canvas center if x/y/w/h are omitted, which helps agents decide whether to supply geometry. It doesn't discuss when to prefer other layer-adding siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the operation can overwrite an existing keyframe, that the curve is anchored to the clip, that moving the clip carries the ramp without changing duration, that rate multiplies the layer's constant speed, and that timeline length derives from the curve. This is comprehensive and non-obvious behavioral context.

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 dense but every sentence earns its place, starting with the core action and immediately clarifying the change-over-time behavior, then addressing the key timing constraint, the constant-speed alternative, and rate semantics. No filler or redundant restatement of the schema.

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?

Given the tool's complexity, the absence of annotations, and the lack of an output schema, the description is remarkably complete. It tells the agent what the tool does, when to use it, what constraints exist, how parameters behave, and what side effects occur. No critical usage information is missing.

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?

Although the schema covers all four parameters at 100%, the description adds substantial meaning beyond the schema: frame must be at or after timeline_start_frame, the curve anchors to the clip, rate values map to real-time/half-speed/double-speed, and the clip's timeline length is derived from the curve. This significantly enhances an agent's ability to pick correct parameter values.

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 description names a specific verb and resource: 'Add or overwrite a speed-ramp (time-remap) keyframe on a video layer.' It also clarifies the key differentiator, that the rate changes over the clip, and explicitly contrasts this with set_clip_speed for constant speed changes. An agent can immediately identify what this tool does and why it exists.

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?

The description explicitly tells the agent when to use this tool versus an alternative: 'For a constant slower/faster clip use set_clip_speed instead.' It also states the frame must be a project-timeline frame and must sit on the clip, giving clear positional requirements for invocation.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses defaults (centre x/y, 900x320, Anton, derived text_size), mutation semantics (creation + returned id), timing behavior (omitting block = always present, keyframes relative to `start`), curve direction conventions (positive = smile, negative = arch), and edge cases (decorations not rendered on curved text). This is unusually transparent for a create tool.

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 dense and well-structured, front-loading the core action and then layering defaults, styling options, and return value. It is long, but every section adds operational value. The only minor redundancy is that some parameter details (e.g. autofit semantics) are repeated in the schema, but in context this repetition helps an agent avoid schema-diving.

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 creation tool with no output schema and no annotations, the description is remarkably complete. It covers defaults, derived behaviors, keyframe timing semantics, curve constraints, autofit modes, return value, and edge cases. An agent has enough context to call this correctly and interpret the result without auxiliary documentation.

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 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema: concrete defaults (canvas centre, Anton, 900x320, derived text_size), the practical watermark/lower-third use case for omitting `block`, the live shrink-wrap guarantee of 'hug', the smile/arch convention for `curve`, and the return value. This far exceeds what the schema alone communicates.

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 description opens with a specific verb+resource: 'Create a new text layer'. It further distinguishes this tool from siblings by characterizing the layer as 'a first-class leaf that animates, groups, and z-orders exactly like an image or shape', and by stating the renderer draws 'live typeset text'. This makes it clearly distinct from add_image_layer, add_shape, set_layer_text, and add_caption_track.

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?

The description gives strong parameter-level guidance, such as omitting `block` for watermark/lower-third overlays and using specific autofit modes, but it never explicitly tells an agent when to choose add_text_layer over sibling tools like add_caption_track or add_image_layer. Usage is implied by the tool's purpose rather than declared with exclusions or alternatives, so this is adequate but not exemplary.

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

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

With no annotations available, the description carries the full burden of behavioral disclosure. It does so well by stating that adding creates an immutable, self-contained copy of the whole subtree plus asset bytes, and that later edits or deletions of the source do not affect existing copies. This goes beyond a simple 'adds to collection' statement, though it does not cover every possible side effect such as permission requirements.

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 core action and accepted inputs are front-loaded in the first sentence, with subsequent sentences adding important behavior about immutability, workspace sharing, and naming. It is long, but every sentence earns its place by clarifying usage and consequences rather than repeating schema data.

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 two-parameter tool with no output schema, the description is complete: it explains what to pass, where the layer appears, how copies behave, how teammates can use it, and what prerequisite to satisfy first. An agent has enough context to select and invoke the tool 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?

Both parameters are already fully described in the schema at 100% coverage, so the baseline is 3. The main description reinforces that elementId can be a leaf or group.<id> and that projectId selects the existing project to mutate, but it does not add substantial new meaning beyond 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?

The description clearly states the action: 'Add a layer to the user's reusable Collection,' and specifies what kinds of element IDs are accepted (leaf or group.<id>). It also differentiates itself from related siblings by explicitly mentioning list_collection and add_from_collection, so the agent understands the exact role of this tool.

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?

The description names the relevant alternatives: list_collection for viewing the collection and add_from_collection for dropping a copy into another project. It also explains when this works (solo projects and workspace projects) and advises renaming layers first with rename_layer/rename_group, giving strong guidance on when and how to use the tool.

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

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

With no annotations provided, the description carries the full behavioral burden. It does a good job by disclosing the hard prerequisite that the clip must already exist and the special behavior that reusing a clip filename causes the editor to auto-assign a fresh id. It does not mention return values, failure modes, or permission requirements, but for a simple additive operation these are less critical gaps.

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 compact and well-structured: the core action comes first, followed by the prerequisite and a practical usage tip. Every sentence earns its place without unnecessary elaboration.

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?

Given the 100% schema coverage and the relatively simple flat parameter set, the description provides enough context for an agent to call the tool correctly: the non-obvious prerequisite and the duplication behavior are both explained. The absence of an output schema means return shape is not described, but that is a minor gap for this kind of additive operation.

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 adds real value for the clip parameter by specifying the upload path and the duplicate-by-reuse mechanism, which are not derivable from the schema alone. It does not add meaning for x, y, width, height, or name, but the schema already documents those adequately.

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 description states the specific action and resource: 'Add a video layer.' The 'video' modifier distinguishes it from sibling tools like add_image_layer and add_text_layer, and the duplicate-by-reuse note further clarifies what this tool is for.

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?

It clearly explains the prerequisite that the clip must already exist at a specific storage path and gives the upload endpoint. It also provides guidance for duplicating an existing layer by reusing the clip filename. It does not explicitly name sibling tools or state when not to use it, so it misses the exclusionary guidance that would make it a 5.

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

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

With no annotations available, the description carries the full burden of behavioral disclosure. It only says 'Apply', implying a mutation, but does not explain side effects on existing layer properties, whether the preset replaces or overlays existing animations, or whether the operation is reversible. This is minimal behavioral context for a mutating tool.

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 a single, well-structured sentence that immediately conveys the core operation. It is appropriately sized, front-loaded, and contains 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 tool with four parameters, an enum, no annotations, and no output schema, this description is too sparse. It omits behavioral context, fallback behavior, error cases, and relationship to sibling animation tools like apply_preset_stagger. An agent would likely need to inspect other resources or guess about side effects and return values.

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 50%, covering projectId and startFrame but not elementId or preset. The description adds useful context that the preset is an animation and the target is a layer, which helps interpret elementId and preset, but it does not articulate how startFrame interacts with presets or whether elementId refers to a layer ID specifically. It partially compensates for the schema gap without fully completing parameter meaning.

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 description 'Apply a canned animation preset to a layer' clearly names the action (apply), the object (a canned animation preset), and the target (a layer). It does not explicitly contrast with the closely named sibling apply_preset_stagger, so it misses the chance to differentiate, but the core purpose is unambiguous.

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?

No guidance is provided on when to use this tool versus alternatives such as apply_preset_stagger, fade_layer, or manually adding keyframes. The description simply states the operation without contextual selection criteria or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It transparently notes that the project is mutated and gives the exact offset formula, but it doesn't mention whether existing animations are overwritten, whether the call is idempotent, or what happens on failure/results returned.

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 compact and well-structured: it states the core behavior, gives examples, and then provides the formula and ordering rule. The example use cases add a little length but are useful context rather than 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?

All behavior needed to call the tool correctly is covered: the parameters, defaults, ordering, and mutation target. There is no output schema, but for a mutation-focused tool the absence of return-value documentation is not a significant gap.

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?

Four of five parameters have meaningful descriptions, including elementIds ordering, startFrame base, stagger increment, and projectId selection. The preset parameter lacks a description but its enum values are self-explanatory, so coverage is strong overall.

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?

Clearly states that the tool applies the same preset to a list of layers with per-element startFrame offsets, and explicitly contrasts it with making N apply_preset calls. It also gives concrete use cases (diagonal pop-in grids, sequential list reveals) that distinguish it from the sibling apply_preset tool.

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?

Explains when to use the tool and how the stagger formula works, plus the need to order elementIds by cascade order. It doesn't explicitly say when not to use it or compare with fade_layer/add_keyframe, but the 'one call instead of N apply_preset calls' guidance is sufficient for most cases.

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

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

With no annotations given, the description carries the full burden of explaining behavior. It discloses that processing runs client-side, that the preview proxy is always built, and that the tool returns a structured status object. It also explains the status enum values. While it doesn't mention auth or side effects, for a read-only status tool this is adequate transparency.

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 verbose and includes redundant statements (e.g., 'Processing never runs on the server' followed by a detailed client-side explanation, and the return format is described twice). While the structure is logical—purpose, processing details, return schema, use cases—it could be tightened substantially without losing clarity.

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?

The description is complete for a status-query tool: it fully explains the return object, the meaning of each status value, and how to interpret the results. It also connects to related tools (transcribe_clip, detect_text_regions) and explains the mandatory proxy step. No essential context is missing, though it could be more concise.

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?

The schema already provides full descriptions for both parameters: projectId and clip (with the filename format and omit-to-report-all behavior). The tool description repeats this information without adding significant new meaning. It does contextualize how the parameters affect the returned data, but the schema coverage is already 100%, so the description adds only marginal value.

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 description states the tool's exact purpose: reporting whether a clip (or all clips) has gone through the video-processing pipeline. It enumerates the specific steps (proxy build, audio split, transcription, OCR) and gives concrete use cases, leaving no ambiguity about what the tool does.

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?

The description explicitly says 'Use it to know whether transcribe_clip / detect_text_regions will return data, and to surface an unprocessed state.' This provides clear when-to-use guidance and ties it to sibling tools. It also clarifies the optional vs. required parameters, though it doesn't delve into alternative query tools.

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

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

Describes the side effects (no email, no human), the returned token, and important limitations (no AI credit envelope, no sign-in) with no contradictions to annotations.

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 contains redundant and tangential instructions about sharing projects and rendering MP4s, making it longer than necessary for a simple account creation tool.

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?

Provides the essential workflow details (token usage, sharing guidance), though the extra rendering instructions are somewhat off-topic and could be trimmed without losing core context.

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?

The single parameter 'name' is fully described with a clear purpose and an example ('name of the agent or the task'), significantly enhancing the schema's minimal info.

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 description clearly states a specific verb ('Create a fresh Morpha account') and a distinct resource ('account'), making it unambiguous and distinguishable from all sibling tools like create_project.

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 instructs to 'Call this FIRST when you have no key' and explains how to use the returned token in subsequent requests, providing clear when-to-use guidance.

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

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

With no annotations, the description carries the full burden of disclosing side effects. It covers return value, workspace placement rules, role requirements, failure on view-only clone sources, and the need for the user to reload the editor—all important behavioral details.

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 well-structured and front-loaded with the core action, but contains some redundancy (e.g., repeating the 'follows the source' rule for workspaceId and fromProjectId). It is dense and useful, though slightly verbose.

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?

Given the tool's complexity (3 optional parameters, no output schema), the description fully covers inputs, return value, failure modes, permissions, and post-creation behavior. It leaves no significant gap in understanding how to invoke the tool.

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?

All three parameters are described in the schema with rich semantics: name is a recommended label, workspaceId defines placement with null forcing personal space, and fromProjectId enables cloning. The description adds context beyond the schema, such as fallback to opaque id and what cloning copies.

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 description clearly states the tool creates a new project and returns its server-minted id, distinguishing blank creation from cloning. It references related concepts like duplicate_project and list_workspaces, making the purpose unambiguous.

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?

It explicitly explains when to use fromProjectId, how workspaceId determines placement, and the default behavior for both cloning and blank projects. It also notes failure conditions and the need for edit-capable roles, giving complete usage guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it is exceptionally thorough: it explains ripple-delete effects, keyframe/marker/audio-overlay shifting, layer trimming versus splitting, audio-overlay truncation, the speed-ramp refusal, composition-length shrinking, and frame indexing/clamping. This is far beyond what the schema conveys and leaves little hidden behavior.

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 core action is front-loaded in the first line, and every subsequent clause adds a distinct behavioral or edge-case fact rather than restating the schema. Although dense, the description is appropriately sized for the complexity of a ripple-delete operation with source-aware splitting and refusal conditions.

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?

Given no annotations and no output schema, the description is remarkably complete for invocation: it covers coordinate conventions, clamping, inclusive/exclusive boundaries, affected element types, layer-specific behavior, refusal conditions, and length-shrinking consequences. An agent has enough information to call this tool correctly and predict its side effects.

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 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: frames are '0-indexed project-timeline frames at 30 fps', endFrame is exclusive and clamped, and the delta calculation is defined. This clarifies how the two numeric parameters interact and what coordinate space they live in.

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 description opens with a specific verb and resource: 'Ripple-delete a time window [startFrame, endFrame)' on the project timeline, clearly defining the operation and its NLE semantics. It further distinguishes itself from sibling mutation tools by detailing source-aware layer trimming/splitting and the refusal on speed-ramp keyframes, so an agent can unambiguously identify what this tool does.

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?

The description gives clear operation context and an explicit when-not condition: it 'REFUSES to cut across a video layer that carries speed-ramp keyframes' and prescribes the remedy ('remove them, or cut outside that layer's span, first'). It does not name alternative sibling tools, so it stops short of fully explicit alternative routing, but the constraints are actionable enough for correct selection.

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

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

Explains the effect on the active page and active_index, and identifies failure conditions, but does not explicitly flag the destructive nature of the operation beyond the verb 'remove'.

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?

Two concise sentences front-load the action and include necessary edge-case details without redundancy or irrelevant information.

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?

The description is complete for a mutation tool with no output schema: it specifies what is removed, required parameters, failure conditions, and resulting active-page behavior.

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?

Both parameters have schema descriptions that fully cover their meaning; the prose adds context about active-page behavior but does not significantly augment the parameter documentation.

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?

Clearly states the action ('Remove the page at `index`') and the resource it operates on, distinguishing it from project-level deletion and page reordering tools.

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?

Provides clear context and important edge-case constraints (fails on out-of-range index or when only one page remains), though it does not explicitly name sibling alternatives.

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

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

With no annotations, the description carries full responsibility for behavioral transparency. It explicitly states the action is permanent, describes the security behavior (opaque not-found for unauthorized users), and notes that the editor session won't auto-refresh—all important side effects the agent should know.

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 concise, using three sentences to convey the action, permissions, and side effects without redundancy. Every sentence adds valuable information, and there is no fluff or unnecessary detail.

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?

Given the simple tool (one parameter, no output schema), the description is thorough: it covers the action, the full scope of deletion, access control, an edge case (last project), and post-deletion behavior. No critical information is missing for the agent to invoke the tool 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?

The only parameter, projectId, has a clear description ('Project to delete.') and schema coverage is 100%. The description adds meaning beyond the schema by indicating the parameter identifies the project to be deleted, which is exactly what the agent needs.

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 description clearly states the tool's function: permanently delete a project and lists all associated data (JSON, shortlist, versions, uploaded assets, clips). It uses the specific verb 'delete' and the resource 'project', making it distinct from sibling tools like duplicate_project or rename_project.

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?

The description provides usage context by specifying access requirements (edit access, owner, workspace editor/admin, direct-share editor) and notes that deleting the last project is allowed. While it doesn't explicitly mention alternatives, none exist for deletion, and the permissions note helps the agent understand when the tool will succeed. A minor gap is not explicitly stating 'use this when you want to delete a project', but it is implied.

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

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

The description mentions the idempotent nature of deletion and the gap behavior in the v<N> sequence, which are important behavioral details. However, it does not explicitly warn about the irreversibility of the deletion, though 'permanently delete' implies it. Overall, it provides good transparency given the lack of annotations.

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 concise, with three sentences covering purpose, input formats, and behavioral notes. There is no redundant or extraneous information, and the structure is clear and direct.

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 simple delete operation, the description covers the essential aspects: what it deletes, how to specify the version, and the idempotency. It does not mention potential error cases or side effects, but given the tool's simplicity, it is relatively complete. The lack of an output schema is acceptable as the tool likely returns a status or nothing.

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?

Both parameters (projectId and versionId) are already described in the schema. The description adds context about the v<N> shorthand and gap behavior, but these are more about tool behavior than parameter semantics. Since schema coverage is 100%, the description provides minimal additional parameter-specific value.

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 description clearly states the tool's function: 'Permanently delete one saved version'. It also distinguishes the tool from siblings like rename_version, save_version, restore_version, and list_versions by focusing on deletion and the specific input formats.

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?

It explains the two acceptable input formats (UUID or v<N> shorthand), and notes that the v<N> sequence keeps gaps, which helps agents understand the behavior. It also states that deleting a non-existent version is a no-op, providing clear guidance on expected outcomes.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses exclusions (keyframe values/styles are unbounded), the active-page behavior, and the exact pages block shape. However, it never explicitly states the call is read-only, and the input schema's projectId description claims this call 'mutates' the project — an inconsistency the tool description does not preempt.

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?

All five sentences earn their place: core scope and return content first, exclusions second, multi-page caveat third, then routing to inspect_layers and a final guardrail. Dense but every clause carries signal; nothing is 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?

No output schema exists, and the description compensates by detailing the return values (canvas, duration, z-ordered tree fields, pages block) and the multi-page edge case. The only gap is the unresolved read-only question: the schema's 'mutates' wording plus a missing explicit no-side-effects statement leaves slight ambiguity for a tool that is clearly an overview.

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 100%, so the baseline of 3 applies even though the description adds no parameter-specific syntax. The description's multi-page note indirectly clarifies what projectId selects (the active page), but the schema text itself is misleading: 'Selects which existing project this call mutates' is wrong for a read-only overview tool.

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: a structural overview / table of contents of the composition, enumerating exactly what it returns (canvas size, duration, backdrop summary, z-ordered layer tree with elementId, type, geometry, animated properties). It explicitly differentiates itself from inspect_layers and the page-management siblings, so an agent can select it correctly without opening schemas.

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 sequencing: 'Start here, then call inspect_layers' for full detail on the layers to change. It also names the exact alternatives for page management (select_page, add_page, delete_page, reorder_pages) and warns 'Don't guess keyframe/style values from this overview,' covering both when-to-use and when-not-to-use.

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

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

With no annotations, the description carries full behavioral burden and does so thoroughly: sampling cadence (0.3s), image OCR happening once, R2 caching, not-ready status, source-pixel coordinate space, confidence range, and axis-aligned boxes are all disclosed.

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 but densely packed; every clause adds operational detail, return-shape clarification, a coordinate caveat, or a usage rationale. It is front-loaded with the core purpose and input constraint before diving into output details.

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?

Even without a formal output schema, the description fully defines the return shape, field semantics, frame behavior for images, and coordinate space. The only minor omission is retry guidance for 'not-ready', but the overall context is rich enough for an agent to call 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 schema already documents all three parameters. The description reinforces clip-vs-image exclusivity and filenames but does not materially add parameter meaning beyond 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?

The description opens with a specific verb and resource: 'Return the OCR text regions detected in a clip's video frames OR a still image asset.' It distinguishes itself from audio-oriented siblings like transcribe_clip by focusing on OCR text and naming both input forms.

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?

It gives clear selection constraints ('Pass either clip or image — not both') and an explicit use case ('Use to know where titles / subtitles / lower-thirds are baked into the video or image'). It does not name alternatives to avoid, so it stops short of full when-not guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the cumulative transform semantics precisely (offset by i, rotation by i, scale by d_scale^i), states that styles are copied, and suggests how to animate the result. It doesn't explicitly say the original remains unchanged or describe the returned structure, but the cloning behavior is well implied.

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 front-loaded with the core definition, then provides a compact formula, avoids redundancy with the schema, and uses brief illustrative examples to clarify intended use. Every sentence contributes to understanding the tool's purpose, behavior, or typical application.

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 7-parameter primitive with no output schema and no annotations, the description is thorough: it explains the transform model, enumerates acceptable element types, gives usage patterns, and notes animation follow-ups. It does not specify z-ordering or whether copies are independent layers, but these are minor omissions for an agent invoking this tool.

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?

Although the schema covers each parameter at 100%, the description adds essential semantics beyond the schema: the mathematical relationship between parameters and copies, exponential scaling via d_scale^i, and meaningful parameter combinations. This is exactly the kind of clarification an agent needs to call the tool correctly.

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 description opens with a specific verb-resource pair: 'clone a leaf ... count times', and names the exact element types it accepts (image, video, shapes, text). It clearly distinguishes this from duplicate_project and other sibling operations by framing it as a 'composition primitive' that applies cumulative transforms.

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?

The description gives concrete use cases ('a circle of stars', 'a row of chevrons', 'a fractal', 'a staggered grid') and claims 'One call instead of dozens', implying the alternative is repeated add/duplicate calls. However, it does not explicitly name alternative tools or state when not to use this tool, so there is a small gap in routing guidance.

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

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It discloses naming defaults, id opacity, workspace-following behavior, role requirements, explicit failure behavior for view-only sources, behavior for shared projects, the returned workspaceId, and the editor refresh caveat.

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 but every section earns its place given the tool's complexity. It is front-loaded with the core action and copy scope, uses a clear WORKSPACE marker for the nuanced behavior, and includes no filler or repetition.

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 duplication tool with no annotations and no output schema, the description covers invocation, naming, workspace placement, role requirements, failure cases, and the returned workspaceId. An agent has enough information to call the tool correctly and anticipate side effects.

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?

Although the schema already covers all three parameters at 100%, the description adds significant meaning beyond the schema: the default workspace behavior, what happens when workspaceId is null, the list_workspaces reference, role requirements, and the failure mode. This substantially aids correct parameter selection.

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 description states the exact operation ('Duplicate an existing project into a brand-new one') and specifies what is copied: layers, animations, styles, uploaded assets, and clips. It is clearly distinct from siblings like create_project (creates new) and duplicate_layer (copies a layer).

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?

The description gives clear context on when to use the tool, including what projectId to pass, default behavior, workspace overrides, and failure conditions. It does not explicitly name alternative tools or state when not to use duplicate_project, but the contextual guidance is strong.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core operation, but it does not say whether existing opacity keyframes are replaced, whether keyframes are created at the exact given frames, whether the operation is reversible, or what side effects the mutation has. For a mutating tool, this is a meaningful gap.

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 a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose, and it is immediately scannable for an agent.

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?

With six required parameters, no annotations, and no output schema, this tool needs more behavioral and usage context than a one-liner provides. The description does not explain return values, error conditions, default behavior, or whether the operation mutates persistent project state beyond the implied fade.

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?

The schema covers opacity ranges and projectId, while the description adds useful relational context by framing the parameters as a fade between two frames. It helps connect fromFrame/toFrame and fromOpacity/toOpacity as paired endpoints, but elementId and the frame fields still lack individual documentation, so the description only partially compensates for the 50% schema coverage.

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 description names a specific verb ('Fade'), a specific resource ('a layer's opacity'), and the exact scope ('between two frames in one call'). This makes the tool's purpose unambiguous and distinguishes it from sibling tools like add_color_keyframe or add_keyframe, which handle different or more granular animation operations.

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?

The phrase 'in one call' implies this is the tool to use for a simple two-point opacity fade rather than building the fade manually with keyframes. However, it does not explicitly state when to prefer this over sibling tools like add_keyframes or set_keyframes_batch, nor does it give conditions or exclusions.

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

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

The description discloses key behaviors: downloads and stores in the project asset bucket, returns a filename ready for add_image_layer, falls back to 404 when no suitable image, always returns attribution, and is free (no model spend). No annotations are provided, so this full disclosure is essential and well done.

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 somewhat verbose but avoids fluff. It packs useful examples, caveats, cost info, and alias into a single paragraph that remains easy to parse. Slightly long but acceptable for the complexity.

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?

The description covers the return value, side effects, fallback behavior, attribution, and cost. It does not explicitly tie each parameter to usage scenarios, but the schema already provides that context, so the description is sufficiently complete for correct usage.

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?

The schema descriptions already cover all four parameters at 100% coverage. The tool description adds minimal parameter-specific details beyond the schema, so it does not significantly enhance understanding of the parameters themselves.

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 description clearly states the tool's purpose: search a public image pool, download, store, and return a filename for add_image_layer. It also explicitly differentiates from upload_image, making the tool's role unambiguous.

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?

Provides direct usage guidance with concrete examples (e.g., 'get me a parasol'), explicitly states it is NOT for uploading your own image and directs to upload_image, and notes the workflow benefit (saves upload-then-add_image_layer dance).

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explains the auto-fit rule, the 1-second floor, the headless under-fit edge case involving source_out_frame null, and the eventual self-correction in the editor.

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 compact and front-loaded with the primary purpose, then adds a clearly marked and necessary caveat. Every sentence contributes useful information without fluff or repetition.

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?

Given the simple one-parameter API, the description covers the core behavior, side effects, and an important edge case. It does not explicitly describe the return value or error behavior, but the absence of an output schema makes this a minor gap rather than a blocking one.

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?

There is only one parameter, projectId, and the schema description already fully explains it as an opaque UUID selecting the project to mutate. The tool description adds no additional parameter-level meaning, so the baseline schema coverage score applies.

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 description states a clear action ('Clear an authored composition length') on a specific resource (composition duration) and explains the resulting behavior (AUTO-FIT tracking the furthest content). It also distinguishes itself from the sibling tool set_duration by explicitly labeling itself as the inverse.

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?

The description clearly implies when to use it: after an authored duration has been set, to revert to auto-fit. It names set_duration as the counterpart, giving the agent a route to the alternative, though it does not spell out explicit 'use X instead' exclusions.

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

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

The description explains the exact side effects: the clip is cut, a still is inserted, and everything after is pushed later. It also clarifies that the still becomes an ordinary image layer (resizable, splittable, etc.) and mentions the reply field 'frozenSourceFrame', providing strong transparency into the mutation.

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 highly repetitive, restating the same points multiple times (e.g., the cut-and-insert behavior, the image upload requirement, and the frame constraint). It could be condensed to two or three sentences without losing any information.

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?

The description covers the operation, prerequisites, parameter constraints, and even the reply field 'frozenSourceFrame'. It lacks explicit error handling or return format details, but with no output schema and the given context, it is sufficiently complete.

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?

While the schema already covers each parameter, the description adds meaningful context—e.g., the default holdFrames is 150 frames (5s at 30fps), the image must be an already-uploaded PNG, and frame must be strictly inside the clip. This enriches understanding beyond the bare 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?

The description clearly states that the tool freezes a video frame by cutting the clip and inserting a still image, pushing subsequent content later. This is a precise and unambiguous purpose that distinguishes it from sibling tools like add_image_layer or set_video_clip.

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?

It explicitly frames the use case as 'This is how you hold a moment — play, freeze, continue,' giving practical guidance. It also notes prerequisites like needing the PNG already uploaded and that the frame must be strictly inside the clip, but it does not explicitly contrast with alternative tools.

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

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

With no annotations provided, the description carries full behavioral disclosure. It explains that the group composes x/y/scale/rotation/opacity onto descendants, that pivots rotate/scale around pivotX/pivotY seeded to the child centroid, and that groups have no static body of their own—essential behavioral context beyond a simple 'wrap' statement.

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 but every clause earns its place; it front-loads the action and decision rule, then packs transformation semantics and constraints into the following sentences. The example list is illustrative rather than filler, and there is no redundant restatement of schema fields.

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 grouping tool with complex transform semantics and no output schema, the description is remarkably complete. It covers purpose, use cases, naming importance, composition behavior, pivot seeding, translation offsets, and parent constraints—everything an agent needs to decide and execute the call 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?

The schema already covers all three parameters at 100%, so the baseline is a 3. The description adds meaningful semantic value by explaining that the group name becomes the user's only handle, that x/y values are translation offsets around the pivot, and that elementIds must share one parent—clarifying behavior that the schema does not convey.

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 description opens with a specific verb and resource: 'Wrap sibling elements in a new group.' It clearly distinguishes this operation from sibling tools like rename_group, ungroup_layers, and set_group_box by focusing on the act of grouping loose layers into one named composite.

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?

The description gives explicit, actionable guidance: 'USE THIS whenever several layers are one thing,' backed by concrete examples like a butterfly or an icon. It also states the key precondition that all elementIds must share the same parent, and frames leaving multi-shape objects ungrouped as a defect, clarifying when this tool is the right choice.

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

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

There are no annotations, so the description carries the burden of showing this is a read-only inspection operation. It does so through 'drill-in', 'Returns', and 'about to mutate' as a future step, and it names the exact categories of data returned. It does not explicitly state 'does not modify the project' or mention auth/rate-limit caveats, which is a minor gap.

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 three sentences with no filler: it front-loads the core purpose, then the return payload, then the invocation constraint. Every sentence earns its place and it does not repeat the schema property definitions.

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?

Since no output schema is provided, the description's enumeration of returned content is essential and largely sufficient. It also explains where elementIds come from and how many to pass. However, the exact output shape—whether a map keyed by elementId or a flat array—is not specified, leaving a small completeness gap.

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?

Both parameters are already fully documented in the schema, so this starts at a baseline of 3. The description adds useful selection guidance for elementIds: read them from describe_video and pull detail only for the layers about to be mutated. It adds nothing beyond the schema for projectId.

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 description clearly states what the tool does: 'Full per-element drill-in' that 'Returns each named element's COMPLETE record', and it enumerates the returned content including animation tracks, keyframes, colour/fill tracks, loop modes, and style. It also distinguishes itself from describe_video and the mutating sibling tools by calling itself the 'open this layer' half of the browser and framing mutation as a later step.

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?

The description gives an explicit workflow: pass the elementIds read from describe_video, and inspect only the handful of layers you are about to mutate, not the whole project. This tells the agent when to call the tool, where to get inputs, and how to limit scope, which is strong usage guidance.

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

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

With no annotations, the description carries the full burden, and it delivers: it discloses the exact return shape, explains the scope field semantics, covers the solo-account edge case, and states that no arguments are required. This is far richer than a typical list-tool description.

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 dense but well organized: purpose, return format, field semantics, downstream usage, and edge case. Every sentence contributes information an agent needs, 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?

Given there are no parameters and no output schema, the description supplies everything needed: the response structure, the meaning of each important field, and the connection to add_from_collection. Nothing essential is missing.

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?

The input schema has zero parameters and 100% coverage, and the description explicitly confirms 'takes no arguments.' There is no ambiguity left for an agent about what to pass.

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 action ('List') and resource ('the user's reusable Collection'), and immediately defines what that collection contains with concrete examples. It also references add_to_collection, making the tool's role among its siblings clear.

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?

Clearly describes what the tool returns and how the returned sourceProjectId and elementId feed into add_from_collection, giving an agent strong context for when to call it. It does not explicitly name alternatives or call out when not to use it, but the usage context is unambiguous.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it states the return shape, the sources returned, filtering semantics, default and max limits, and even notes that selected families will Just Work in later calls. No side effects or hidden behaviors are claimed.

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?

Three dense sentences, each earning its place: scope, return shape/filtering, and downstream compatibility. The key purpose is front-loaded, and the details are organized without wasted words.

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 read-only discovery tool with no output schema, it is unusually complete: it documents the returned object structure, sources, pagination cap, filters, and the reason to call it. An agent has enough context 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 coverage is 100%, so the baseline applies. The description restates q, source, and limit semantics that are already in the schema, adding little new parameter-level meaning. It usefully ties results to future font_family usage, but it doesn't deepen understanding of current parameters.

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 description opens with a specific verb and resource: 'List available font families' and enumerates every source, including custom uploads. It also explicitly frames the tool as the discovery step before set_layer_text / add_text_layer, which makes its purpose immediately distinguishable from the large sibling list.

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?

It gives an explicit when-to-use instruction: 'Use this to discover families before set_layer_text / add_text_layer when you don't know what to pick.' It also explains the q/source/limit filtering behavior, so an agent knows exactly how to narrow results.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses the default personal-only scope, the workspace variant with ownerEmail, membership requirements, that ids are opaque and should not be shown, and that editorUrl is a tappable link to offer the user. This is rich, non-obvious behavioral context.

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?

All four sentences earn their place: the output shape, field semantics, default vs workspace behavior, and an explicit usage trigger. The most decision-relevant details are front-loaded, and there is no redundancy.

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 read-only listing tool with one optional parameter and no output schema, the description is complete. It covers the return entries, field meanings, default behavior, workspace behavior, and the right moment to invoke the tool. Nothing critical is missing.

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 for the single parameter is 100%, so the baseline is 3. The description adds value by explaining that workspaceId comes from list_workspaces, that membership is required, and what happens when omitted. This goes slightly beyond the schema's own description.

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 description states a specific verb ('List') and resource ('projects'), and precisely defines the output shape as { id, name, editorUrl } entries. It clearly distinguishes this tool from siblings like list_workspaces and list_versions by focusing on project listing, and further clarifies the role of each output field.

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?

The description gives explicit when-to-use guidance: call it when the user asks 'what projects do I have?' or when the user hasn't named a project but you need to operate on one. It also explains the workspaceId alternative and references list_workspaces as the source for workspace IDs, making the decision path clear.

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

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

With no annotations, the description carries full responsibility and does an excellent job: it reveals the return shape, distinguishes bookmark vs auto versions, explains version_number stability and gaps, and defines the cp field's possible values. This is far beyond a bare 'list versions' statement.

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 dense but every sentence earns its place: it front-loads the core purpose, then explains the return fields and their quirks, then directs the agent to downstream operations. No filler or redundant restatement.

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?

Since there is no output schema, the description must fully explain return semantics, and it does: fields, kind differences, version_number behavior, cp meaning, and how to use the results. For a single-parameter listing tool, nothing important is missing.

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 100% and the single required parameter projectId is already described as 'Project whose versions to list.' The description adds no new parameter-level detail, but none is really needed given the schema already covers it.

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 action and resource: list every saved version of a project, newest-first. It also distinguishes itself by explicitly saying it returns summaries, not the inner project JSON, and names the related restore/rename/delete operations.

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?

Clear context is provided: this tool lists versions and the returned IDs are meant for use with restore_version, rename_version, and delete_version. It implies the read-only listing use case but does not explicitly say when to prefer it over alternatives like open_project or save_version.

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

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

With no annotations, the description fully carries behavioral disclosure. It defines the role field and its permission implication, warns that keyless/dev identities see an empty list due to email-based membership, and instructs the agent to use name for user-facing references and never paste the id.

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?

Every sentence earns its place: output shape, role semantics, workspaceId usage, display convention, and the no-email edge case are all included without repetition. The most important action ('List the workspaces...') is front-loaded.

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?

Given the empty input schema and lack of annotations, the description supplies everything needed to call and use the tool: return shape, role meaning, downstream tools, user-facing display guidance, and an edge-case result. No critical behavior is left unexplained.

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?

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics to document; the description instead focuses on result semantics, which is appropriate.

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 description opens with a specific verb and resource: 'List the workspaces (shared team spaces) the account belongs to,' and enumerates the output fields. It separates workspaces from the sibling list_projects and explains how workspace ids feed other tools, so an agent can select it correctly.

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?

It gives clear usage context: 'Call this to discover a workspace before placing a project into it,' and informs downstream use via workspaceId. It does not explicitly state when to prefer a sibling tool or list when-not conditions, so it stops one step short of a full 5.

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

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

With no annotations, the description carries the full behavioral burden, and it does so well: it discloses that other lines are removed, which line survives, how texts are ordered, and the union window behavior. It stops short of describing error handling or the return value, but the mutation semantics are transparent.

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?

Two tightly packed sentences with no filler. The core purpose is front-loaded, and the constraints are presented in the second sentence without unnecessary repetition of schema details.

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?

Despite having no annotations or output schema, the description gives an agent everything needed to invoke it correctly: input expectations, merge behavior, outcome for non-surviving lines, and track-level preconditions. No critical operational information is missing.

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 100%, so the baseline is 3. The description adds useful semantic detail beyond the schema, such as the requirement for at least two lines, the time-ordering of joined texts, and the same-clip-or-standalone constraint.

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 description clearly states a specific action and resource: merging two or more caption lines into one, with precise behavior ('earliest line survives', 'time-ordered texts joined by spaces', 'others are removed'). It is easily distinguished from sibling tools like split_caption_line or add_caption_track.

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?

It gives clear operational context and explicit preconditions: all lines must share the same flavour and no other caption line may sit inside the merged span. It does not name alternatives or explicitly say when not to use this tool, but the conditions are concrete enough to guide selection.

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

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

No annotations are provided, so the description carries the burden of explaining behavior. It explains that the whole inner reel plays relative to the origin, that the window length is preserved, and what happens when there was no window. It stops short of stating persistence or failure behavior, but the core side effects are disclosed.

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 compact and front-loaded with the main action. Each sentence adds an essential detail: what the origin does, why it matters, the edge-case fallback, and where to find the band id. No filler or duplication.

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 3-parameter tool with no output schema and no annotations, this is well covered: purpose, behavior, edge case, and param source are all present. The only omissions are minor, such as explicit persistence or error behavior, and they do not block correct selection or 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 coverage is already 100%, giving a baseline of 3. The description adds real meaning: start is the TIME ORIGIN and bandId must be a morpha group id from describe_video, which maps directly to how the tool should be invoked. projectId's role is already 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?

The description uses a specific verb and resource: 'Place an embedded morpha band on the host timeline' and 'set its TIME ORIGIN'. It immediately distinguishes the operation from generic layer commands like move_layer and add_morpha_layer by scoping it to embedded morpha bands and their start frame.

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?

It gives concrete context for when to use the tool: it is 'the fix for the embedded intro doesn't animate', and tells the caller to pass a band group id from describe_video where morpha:true. It does not explicitly enumerate exclusions or alternatives, but the usage scenario and prerequisite are clear enough.

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

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

With no annotations provided, the description carries the full burden, and it does so substantially. It discloses that group layers only receive pivotX/pivotY (not width/height/rotation), that keyframe tracks override static values at every frame, that scale/opacity writes over animated properties are refused, and that clear_animation:true replaces the animation. It does not narrate the response shape or permissions, but no output schema exists and the mutation behavior is well covered.

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 opening sentence front-loads the core action and field list, then narrows scope by layer kind before addressing animation edge cases. The prose is dense but purposeful; the schema already documents each parameter, so the description wisely focuses on cross-field behavior. Slightly long for a first sentence, but every clause earns its place.

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?

The description robustly covers the tool's edge cases, group behavior, animation interactions, and coordinate-space pitfall for a 10-parameter mutation tool with no annotations and no output schema. It does not explain the return value or error shape, but with no output schema declared and schema descriptions covering all parameters, the missing bits are minor.

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 100%, so the baseline is 3 and the description need not compensate. It adds some useful framing beyond the schema, such as 'writes ... on image.<id>, video.<id>, and shapes.<id>' and the note about group layers, but most parameter semantics (units, clamping, coordinate spaces) already live in the schema. The description does not significantly deepen parameter understanding beyond the schema's own descriptions.

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 description names a specific verb ('Set') and a precise resource ('a layer's static base transform') and enumerates exactly which fields are written for which layer kinds. It explicitly contrasts with add_keyframe, so an agent can distinguish move_layer from its sibling animation tools.

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?

The description clearly states when to use move_layer: to set static/un-animated defaults, and explicitly says to use add_keyframe for group rotation and for animating properties. It also explains the refusal behavior when a keyframe track exists and instructs passing clear_animation:true to replace animation. The in-schema coordinate guidance ('inside a group it is the group's space') clarifies the context for using x/y.

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

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

Discloses permission requirements (edit-capable role in target workspace, write access to project) and a side effect (drops old membership). Since no annotations are provided, this transparency is essential and fully delivered.

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?

Description is concise (four sentences) and front-loaded with the main purpose, followed by usage specifics, permissions, and side effects. Every sentence contributes essential information.

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?

All relevant aspects are covered: what the tool does, how to use it in each case, what happens (including permissions and side effects), and the null scenario. No output schema exists, so return values do not need explanation.

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 already covers both parameters with matching descriptions, so the tool description adds minimal extra value. However, it adds the hint to get workspaceId from list_workspaces, which slightly enhances understanding beyond 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?

Clearly states 'Move a project into a workspace, or back to the caller's personal space' – a specific verb and resource, and distinguishes the two modes of operation.

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?

Provides explicit instructions for both cases: pass workspaceId to place in workspace, pass null to move to personal. Also references list_workspaces for obtaining IDs, giving clear context on how to use the tool.

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

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

With no annotations present, the description carries the full transparency burden. It discloses the return shape, the key behavior that the editor loads exactly the given project from the URL, and the expected user-facing follow-through. It does not cover failure cases or side effects, but for a link-generation tool this is reasonably transparent.

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 concise and front-loaded with the core purpose before the usage guidance. Every sentence adds useful information: what the tool returns, when to invoke it, and how to present the result. There is no wasted or redundant content.

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?

This is a low-complexity tool with one fully documented parameter and no output schema, so the description must explain the return value itself — which it does. It also provides clear invocation context and user-handling instructions. Nothing needed for correct selection and invocation is missing.

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 for the single parameter projectId is 100%, so the schema already documents what the parameter means. The description does not add extra parameter-level detail beyond the schema, which matches the baseline of 3 for high schema coverage.

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 description opens with a specific verb and resource: "Get a tappable link that opens a project directly in the editor." It also states the exact return value, { name, editorUrl }, and explains the distinguishing behavior that the editor loads exactly this project from the URL. This clearly separates it from sibling project tools like list_projects or rename_project.

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?

The description gives explicit triggers: use it when the user wants to view their work, after making a change, or when they say "show me" / "open it." It also instructs the agent to pass the editorUrl to the user and refer to the project by name. However, it does not mention when not to use it or name any alternative tool, so it stops 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.

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses the destructive deletion of the old id, the lossless re-keying of JSON/versions/assets/clips, the enforced v4 UUID policy, and the editor refresh caveat. This is exemplary transparency for a mutating tool.

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?

Every sentence earns its place: the opening sentence states the core action and scope, then the description covers the sibling contrast, UUID policy, user-facing impact, and refresh caveat without padding. Despite its density, it remains scannable and front-loaded.

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 destructive mutation with no annotations and no output schema, this description is exceptionally complete: it explains the effect on all project data, the old id deletion, the ID policy, the parameter behavior, and the post-operation UI caveat. An agent has enough context to call it correctly and anticipate consequences.

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?

The schema already has 100% parameter coverage, giving a baseline of 3. The description adds meaningful semantics beyond the schema by explaining the optional newId behavior, the v4 UUID requirement, and the automatic minting when newId is omitted.

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 description names a specific verb ('Change a project's id') and resource, and goes further by stating the lossless re-keying scope and contrasting with create_project. It is unambiguous and distinguishes itself from rename_project by noting the user-facing name is untouched.

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?

The description gives clear context by explicitly contrasting with create_project (clone) and noting version history preservation, so an agent understands when reid_project is appropriate. It does not enumerate exclusions or other alternative tools, but the context is strong enough to guide selection.

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

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

The description only states 'Delete' without disclosing side effects, reversibility, or error conditions. Since no annotations are present, the description carries the full burden of behavioral transparency, which it does not fulfill.

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 a single, succinct sentence that conveys the core function without unnecessary words. It is well-structured and immediately understandable.

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 simple delete operation, the description is adequate in the context of the schema and sibling tools. However, it lacks details about what happens to the project or other overlays, and does not explain the 'audio overlay' concept. Given the absence of annotations, a bit more context would improve completeness.

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?

The schema descriptions for both parameters are clear and specific, covering all parameters (100% coverage). The description itself adds no additional parameter information, but the existing schema is sufficient, warranting the baseline score of 3.

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 description clearly states the action ('Delete') and the resource ('audio overlay') with a specific identifier. It is concise and unambiguous, though it does not explicitly distinguish it from similar delete tools beyond the resource type.

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?

No guidance is provided on when to use this tool instead of alternatives (e.g., remove_layer, delete_page). It does not mention prerequisites, effects on related entities, or any context for selecting this tool over others.

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

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

With no annotations, the description covers important side effects: no-op when no track or matching keyframe exists, and dropping the track entry when the last keyframe is removed. However, it does not mention any other side effects (e.g., property reset).

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 two concise sentences with no redundant information, effectively communicating purpose and key behaviors.

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?

Given no output schema and no annotations, the description provides sufficient behavioral detail for a removal tool, including no-op and last-keyframe effects. It lacks explicit return value or error handling info, but is reasonably complete.

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 50% with only elementId and projectId described. The description adds context that frame refers to an exact frame and property is fill, but does not fully compensate for the missing parameter details.

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 description clearly states the tool removes a colour keyframe at an exact frame on a fill track, distinguishing it from generic keyframe removers like remove_keyframe and remove_speed_keyframe.

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?

Provides clear context that this is for colour keyframes on fill tracks, and describes no-op behavior and the effect of removing the last keyframe, but does not explicitly mention when to use this over alternatives.

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

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

No annotations are provided, so the description carries the full burden. It discloses two important behaviors beyond the basic remove operation: idempotency (absent entries are a no-op) and the critical side effect that removing the last entry turns embedding OFF and makes the public embed endpoint 404. This is exactly the kind of behavioral context an agent needs.

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 three short sentences, with the core purpose first, followed by the idempotency guarantee and the critical side effect. Every sentence earns its place; there is no filler or repetition.

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 simple two-parameter mutation with no output schema and no annotations, the description plus schema cover the operation, idempotency, side effects, origin normalization, and project ID provenance. It could be slightly more complete by explicitly routing to set_embed_origins for wholesale allowlist replacement, but nothing essential for calling the tool correctly is missing.

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%, and both parameters (origin and projectId) already have detailed descriptions covering normalization, source, and mutation target. The tool description adds no additional parameter-level semantics beyond what the schema provides, so the baseline of 3 applies.

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 description opens with a specific verb and resource: 'Remove one hostname from the project's embed allowlist.' This clearly distinguishes the tool from sibling tools like add_embed_origin and set_embed_origins. The scope and target are unambiguous.

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?

The description implies usage—use this when you need to remove one hostname from the allowlist—and adds useful idempotency context. However, it does not explicitly mention alternatives like set_embed_origins for replacing the entire allowlist, or add_embed_origin for adding entries. Guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It states that the operation removes from the collection, that placed copies remain unaffected because they are self-contained, and that it is a no-op for missing ids. This is strong transparency for a simple mutation.

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 three tight sentences with the primary purpose front-loaded. Every sentence earns its place: purpose, parameter guidance, side-effect clarification, and edge-case behavior. There is no redundancy or 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 two-parameter mutation with no output schema and no annotations, the description plus schema fully covers what an agent needs: what the tool does, what it doesn't affect, how to supply the id, and what happens on a no-op. No critical behavior is missing.

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 schema already documents both elementId and projectId. The description adds useful context that the element id must be the one used with add_to_collection, but it doesn't substantially expand parameter meaning beyond 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?

The description uses a specific verb and resource: it removes a layer from the user's Collection so it is no longer offered for reuse. This clearly differentiates it from sibling tools like remove_layer, which targets project layers, and directly relates it to add_to_collection.

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?

The description gives clear context on when to use the tool: remove an element previously added via add_to_collection. It also explains that copies in other projects are unaffected and that the operation is a no-op if the id is absent. While it doesn't explicitly name alternatives like remove_layer, the collection-specific framing makes the intended use clear.

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

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

No annotations are provided, so the description carries the behavioral burden. It adds useful context by explaining that removing the last keyframe restores the static base value across the timeline, and 'remove' conveys destruction. However, it does not describe error behavior when no keyframe exists at the given frame, irreversibility details, or what the tool returns.

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 concise and front-loaded: the first sentence states the core operation, and the second adds a valuable behavioral consequence without any wasted words.

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?

Given the tool's destructive nature, four required parameters, no annotations, and no output schema, the description covers the essential operation and one key behavior. It remains incomplete by not explaining what happens if there is no keyframe at frame N and by not clarifying how it differs from the specialized keyframe-removal siblings.

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 25%, so the description must compensate. It clarifies that frame refers to a keyframe position and that the operation targets a layer's track, but it leaves elementId implicit and does not elaborate on the property parameter beyond the schema's enum.

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 description states a specific action and resource: remove a keyframe at a frame on a layer's track. It is clear about what the tool does, though it does not explicitly differentiate from sibling tools like remove_color_keyframe or remove_speed_keyframe.

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?

There is no guidance about when to use this tool versus remove_color_keyframe, remove_speed_keyframe, add_keyframe, or set_keyframes_batch. The note about the last keyframe is a behavioral consequence, not an explicit usage condition or alternative selection.

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

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

The description discloses the side effect of deleting a video layer: it removes welded audio overlays and caption lines. It also mentions the errors on group and pinned layers. Since no annotations are provided, this full behavioral disclosure is essential and covers the key consequences.

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?

Two sentences, no fluff. All information is relevant and directly supports tool selection and usage.

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 deletion operation, the description covers the main action, the applicable scope, the error cases, and the side effects. No output schema exists, so return-value documentation is not required. The description is complete enough for correct use.

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?

The schema already provides 100% coverage for parameters (elementId and projectId with descriptions). The description does not add any extra parameter-specific guidance, so the baseline of 3 is appropriate.

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 description clearly states the action (delete a leaf layer) and explicitly distinguishes it from sibling tools like delete_page or delete_project. It also notes the constraints (leaf only, errors on group and pinned layers) and points to ungroup_layers as an alternative.

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?

It explicitly states when to use (leaf layers) and when not to (group or pinned layers), and even names the alternative tool (ungroup_layers). This leaves no ambiguity about the appropriate context.

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

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

With no annotations, the description carries the behavioral burden and does disclose a non-obvious side effect: 'Removing the last keyframe clears the speed_keyframes array entirely (restoring 1× playback).' It also clarifies the frame coordinate system to prevent off-by-one mistakes. It does not cover error behavior when no keyframe exists at the given frame, but the main destructive consequence is made transparent.

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 two focused sentences with the action and object front-loaded. The parenthetical about frame alignment and the final side-effect sentence both earn their place; there is no filler or repetition of schema content.

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 three-required-parameter mutation tool with no annotations and no output schema, the description is largely complete: it defines the frame context, links it to related tools, and warns about the last-keyframe behavior. The remaining gap is unspecified behavior when no keyframe exists at the given frame, but the essential invocation details are present.

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?

The input schema already documents all three parameters (100% coverage), so the baseline is 3. The description adds only marginal semantic value by reinforcing that `frame` uses the same project-timeline coordinate system as related tools, but it does not substantially expand on the schema's parameter explanations.

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 description states a specific action and resource: 'Remove the speed-ramp keyframe at `frame` ... on a video layer.' It distinguishes itself from generic keyframe removers by specifying the speed-ramp keyframe category and cross-referencing add_speed_keyframe and inspect_layers.

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?

The description provides useful context by noting that `frame` is 'the same value add_speed_keyframe and inspect_layers report,' and it implies the tool is for speed-ramp keyframes on video layers. However, it does not explicitly name alternative removal tools or state when not to use them, so usage guidance is mostly implied rather than explicit.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. 'Pure cosmetic' and 'labels appear in the Inspector and describe_video output' effectively communicate the side effect and exclude structural/positional changes. It still does not cover authentication or reversibility, but the core behavior is transparent.

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 two short sentences with no filler. It front-loads the operation and then adds a valuable behavioral qualification, so every sentence earns its place.

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?

The tool is simple and the purpose/effect are well conveyed. However, with no annotations and no output schema, the description should help more with the required inputs, especially groupId which is opaque and has no source reference such as inspect_layers or group_layers.

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?

The schema only describes projectId; groupId and name have no property descriptions, and the description does not sufficiently compensate. The label/Inspector statement indirectly clarifies the meaning of name, but the required groupId is left entirely unexplained, which is a real gap for a required parameter.

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 description begins with a concrete verb and resource: 'Rename a group' and immediately qualifies the consequence: only the label changes and it appears in the Inspector and describe_video output. This strongly distinguishes it from group geometry/behavior tools such as set_group_box and set_group_parent, and from rename_layer or rename_project.

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?

The description gives clear context by stating the operation is purely cosmetic, so an agent can infer it is appropriate only when the group label itself needs changing. It does not explicitly name alternative tools or state when not to use this tool, so it falls just short of full usage guidance.

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

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

With no annotations, the description carries the behavioral burden, and it does so well: it discloses the mutation target, the Inspector-label effect, the embed-attribute side effect, and the empty-string clearing behavior. It stops short of mentioning permissions, undo behavior, or what happens to existing embed references after a rename, but for a simple setter operation this is a reasonable level of transparency.

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 two sentences with no filler: it front-loads the core operation, then adds the two most decision-relevant clarifications (embed-attribute derivation and the group alternative). Every clause earns its place.

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 three-parameter mutation with no annotations and no output schema, the description is complete enough to call correctly: it defines the operation, scope, side effect, clearing behavior, and the sibling to use for groups. The schema documents all parameter formats, and the description adds the behavioral context needed for safe 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 coverage is 100%, so the baseline is 3, and the description adds extra meaning beyond the schema: it explains that the name is the Inspector label and that it drives the `<morpha-video>` embed attribute, with a concrete example. It also reinforces the elementId layer-type pattern, though projectId semantics are left to 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?

The description states a specific verb ('Set') and resource ('human-readable name of a video / image / shape / text layer'), and clarifies the practical meaning of the label via the Inspector and the auto-derived embed attribute. It also explicitly differentiates the tool from rename_group, so an agent can identify the correct operation without ambiguity.

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?

The description says exactly when this tool applies: renaming video, image, shape, or text layers, and explicitly routes group renaming to rename_group. It also gives a concrete use-case example ('renaming a layer to "caption" makes the embed attribute `caption`'), making the selection criteria unambiguous.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses the exact scope of the mutation ('only the picker label') and the special empty-string behavior, but does not mention return values, errors, or permissions.

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?

Two concise sentences immediately convey the action, the special case, and the non-effect on other project aspects. No wasted or redundant wording.

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 simple rename operation with only two parameters and no output schema, the description provides sufficient context about behavior, fallback, and scope. It lacks explicit error/return details, but these are not critical for basic usage.

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?

The schema already covers both parameters with descriptions, including the empty-string behavior. The description adds minimal extra meaning beyond reinforcing the 'picker label' scope, so the baseline for high schema coverage applies.

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 ('Update') and resource ('project's human-readable name'), and clearly distinguishes from sibling tools like rename_group, rename_layer, and rename_version by targeting only the project picker label.

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?

Provides clear context on when to use the tool, including the empty-string fallback behavior and an explicit statement that it does not affect layers, animations, or styles. Does not explicitly contrast with reid_project, but the scoping is clear enough.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly states that only the display name changes, the v<N> identifier is unaffected, both UUID and v<N> are accepted, and empty/whitespace-only names are rejected. It does not mention permissions or response behavior, but the core side effects and validation are transparent.

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?

Three compact sentences each earn their place: one states the operation, one clarifies what is not changed, and one defines accepted inputs and validation. No redundant or filler content.

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 straightforward rename operation with fully documented parameters, the description provides sufficient operational context: target, side effects, accepted identifier forms, and validation constraints. Since there is no output schema, a brief note on the result is missing but not critical for 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 100%, so the baseline is 3. The description adds extra value by reinforcing the accepted versionId forms and introducing the whitespace-only rejection detail, which is more specific than the schema's 'non-empty string' constraint.

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 description names the exact action ('Rename'), the target resource ('a saved version's human-readable label'), and what the user sees. It also distinguishes itself from sibling rename_* tools and version-management tools by clarifying that the v<N> identifier is unaffected, so an agent can select it unambiguously.

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?

The intended use is clear from the first sentence: when you need to change the display label of a saved version in the picker. The description does not explicitly name alternatives or state when not to use it, but the scope is specific enough that no competing sibling tool is ambiguous.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It credibly conveys the non-obvious behavior: newIndex direction (0 = bottom, last = top), the subtree scope, and the root-vs-nested parent contexts. It stops short of disclosing edge cases such as out-of-range or negative newIndex, or what happens when newIndex equals the current position.

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?

Two dense sentences with zero filler; the purpose is front-loaded in the first clause and the index semantics follow immediately. Every sentence carries operational information that an agent needs before invoking the tool.

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 three-parameter mutation with no output schema, the description covers the call-enabling essentials: indexing base, direction, and parent scope. It would be more complete if it explicitly named move_layer as the tool for cross-parent moves and stated behavior for invalid indices, but such gaps are secondary given the simplicity of the operation.

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 67%: newIndex and projectId are documented while elementId is bare in the schema. The description adds genuine value for newIndex by mapping values to z-order positions (bottom/top) and explaining the ungrouped-vs-nested parent scope, going beyond the schema's single line. elementId is the only gap, but it is inferable from the tool name and context.

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 description opens with a specific verb–resource pair ('Move a layer') and immediately scopes it to reordering within the current parent ('within its parent's siblings'), which distinguishes it from cross-parent moves like the sibling move_layer. It also makes the ordering semantics unambiguous: 0-based, 0 = bottom, last = top.

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?

Usage is implied rather than explicit: the description explains the two indexing contexts (ungrouped root list vs nested group children) but never states when to prefer reorder_layer over the near-duplicate sibling move_layer. In a sibling list of 95+ tools, the absence of any explicit when-to-use or when-not-to-use guidance leaves routing to inference.

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