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

Annotations already indicate a mutating, non-destructive, non-idempotent operation. The description adds useful behavioral context: the layer is placed at the playhead position on the specified track. It does not contradict any annotation, though it omits edge-case behavior such as missing active sequences.

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 resource, then give placement details. There is no filler or redundant restatement of the title.

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 single-parameter, no-required-parameter tool, the description plus schema cover what is needed to invoke it. An output schema is present, so return values do not need explanation. It could mention active-sequence requirements, but this is a minor 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?

The schema description covers 100% of parameters, including the default for track_index. The description only echoes 'specified track,' adding no additional meaning beyond the schema, so the baseline 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 specific verb, resource, and scope: 'Add an adjustment layer to the active sequence' with placement details. This clearly distinguishes it from sibling tools like get_clip_adjustment_layer or add_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?

No guidance is given for when to use this tool over alternatives, prerequisites, or exclusions. The description states what it does, but not when an agent should choose it among the many timeline-modification 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?

Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive or idempotent. The description adds the audio-level domain and fade/level-change intent, but it does not disclose whether existing keyframes are replaced or merged, or whether the array should be sorted by time_seconds.

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 or redundant schema repetition. It conveys the action and purpose immediately.

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 an output schema and fully described parameters, this is minimally adequate. However, it omits practical context such as whether the tool applies only to audio clips, whether it appends or replaces existing keyframes, and which sibling tools are better suited for non-keyframed level adjustments.

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 provides full 100% coverage for both parameters: node_id and keyframes with key-level time_seconds and level_db descriptions. The description adds no additional parameter semantics, so the schema carries the burden and 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 uses a specific verb and resource: 'Add audio level keyframes' and explains the intended outcome: 'create fades or level changes.' This is clear and useful, though it does not explicitly distinguish itself from sibling tools like add_keyframe or adjust_audio_levels.

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 a usage scenario ('to create fades or level changes') but offers no explicit when-to-use guidance or alternatives. It does not mention when to prefer adjust_audio_levels or add_keyframe, nor does it state prerequisites such as the clip being an audio clip or having an editable audio track.

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?

Annotations already flag this as a mutating, non-idempotent operation. The description adds behavioral value beyond that by disclosing that the operation is structural only (does not set per-item values) and that value updates require a separate multi-step flow via set_metadata with readback. This contextualizes the tool's side effects beyond the annotation set.

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 no filler: primary purpose, scope exclusion, and alternative routing. Each sentence earns its place, and the core action is front-loaded in the first sentence.

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 3-parameter tool with an output schema present, the description covers the operation's scope, its key limitation, and the alternative path. A minor gap is the absence of prerequisites (e.g., an open project), but the low complexity and existing schema documentation make this nearly 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 description coverage is 100%: all three parameters (field_name, field_label, field_type) already have descriptive entries, including the field_type enum values (0-3). The description adds no parameter-level detail beyond the schema, 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?

States a specific verb ('Add'), resource ('custom metadata field'), and target ('project's metadata schema'). It actively distinguishes itself from siblings by clarifying this creates a schema/column definition only, which separates it from set_metadata, attach_custom_property, and get_metadata.

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 names the alternative ('Use set_metadata with complete Project Metadata XML and readback') and the condition that selects it (updating a value). The 'does not set a per-item value' exclusion tells the agent clearly when NOT to use this 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?

Annotations only indicate readOnlyHint false, idempotentHint false, and destructiveHint false. The description adds useful behavioral context: it verifies stored parameter data only, and render/playback verification remains host-dependent. This goes beyond what the annotations already convey.

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 with no wasted words. The first sentence identifies the action and object; the second sets an important expectation about verification limits. Information is front-loaded and scannable.

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 a fully described input schema and an output schema present, the description provides sufficient operational context and highlights the key verification boundary. It would be slightly stronger with a note about behavior when a keyframe already exists at the same timestamp, but 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?

Schema coverage is 100% and every parameter already has a meaningful description. The tool description does not add parameter-level detail beyond the schema, 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?

States a specific action ('Add and read back') and resource ('a keyframe on an effect property'), which clearly distinguishes it from audio-keyframe and other keyframing siblings. The scope is explicit and an agent can tell what it operates on.

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 the intended scenario by naming the effect-property context and explains the verification scope, but it does not explicitly state when to use this tool over alternatives like set_effect_property or get_keyframes. No when-not-to-use guidance is provided.

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?

Annotations already convey that this is a mutating, non-idempotent, non-destructive operation, so the description only adds the active-sequence-or-clip target behavior. It does not go deeper into prerequisites like requiring an active sequence or what happens when node_id is omitted, so it meets but does not exceed the baseline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler, putting the operation and target first. It is appropriately concise given that the schema carries the parameter-level 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?

For a marker-creation tool with complete parameter documentation and an output schema, the description plus schema is sufficient. The only mild omission is explicitly stating that the active sequence is the default target when node_id is absent, but the node_id description implies this.

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?

Input schema coverage is 100%, and each parameter, including the color mapping and node_id's sequence-vs-clip meaning, is documented in the schema. The description itself adds no parameter details, so the baseline 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 names the exact operation ('Add a marker') and the resource scope ('active sequence or a clip'), which is specific and distinguishes it from siblings like update_marker, delete_marker, and add_marker_to_project_item. It immediately conveys what the tool does and where it operates.

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 states the intended context: adding a marker to the active sequence or, via node_id, to a clip. It does not explicitly discuss alternatives or exclusions, but the target scope is enough to route an agent away from project-item marker operations.

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 does not disclose behavioral details beyond what the annotations already provide. It does not mention whether existing markers are affected, how duplicate names are handled, or what happens when the time_seconds falls outside the clip duration. Despite annotations showing destructiveHint=false, the description adds no meaningful 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 one succinct sentence that front-loads the operation and target. Every word earns its place, and the clarifying parenthetical is efficiently integrated.

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 add operation with a complete input schema and an output schema present, the description covers the essential action and target. However, a short note about how this differs from the sequence-level 'add_marker' sibling would have made it more fully self-contained.

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 parameters are already fully documented in the input schema. The description adds no additional parameter meaning, such as defaults or relationships between time_seconds and duration_seconds. The baseline score of 3 is appropriate here.

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 the specific verb 'Add' and resource 'project item', and the parenthetical '(source clip marker)' clarifies exactly what kind of marker is targeted. This distinguishes it from sequence-level marker operations like the sibling 'add_marker'.

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 about when to use this tool versus the sibling 'add_marker', 'update_marker', or 'list_markers'. The description implies project-item usage but does not explicitly explain why one would choose this over alternatives or mention any prerequisites such as resolving an item_id.

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?

Beyond the annotations, the description discloses that Premiere exposes no supported scripting API for this operation, making it clear the tool is a stub rather than a working mutation. This is significant behavioral context that prevents the agent from expecting a real text overlay side effect.

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 entire description is a single front-loaded sentence that states unavailability, explains why, and provides alternatives. Every phrase carries useful information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an unavailable tool, the description is fully sufficient: it explains the limitation, names the correct alternatives, and avoids leaving the agent to guess whether the operation will work. The presence of an output schema does not require extra explanation because the tool does not execute a real 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?

The input schema already documents all four parameters with full coverage, so the baseline is 3. The description does not add per-parameter meaning, but given the tool is explicitly unavailable, no additional parameter detail is necessary to improve selection behavior.

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 'Unavailable' and gives a concrete reason, so an agent immediately understands this tool cannot perform its nominal action. It also names the exact alternatives (create_caption_track, MOGRT/PNG overlay), which clearly differentiates it from related captioning 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 provides explicit routing guidance: import an .srt/.vtt and use create_caption_track for captions, or use a MOGRT/PNG overlay for title graphics. This tells the agent when not to call this tool and which sibling to prefer.

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 second sentence 'Verify queue presence or the output file independently' discloses that the tool only requests a handoff and does not guarantee the queue item or output file, which is valuable beyond the all-false annotations. It communicates asynchronous/non-deterministic behavior without contradicting the 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?

Two sentences, action first, with the caveat placed second; no filler or repetition of schema/annotation content. 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?

For a two-parameter tool with an output schema and clear scope, the description is mostly complete and includes a crucial independent-verification caveat. It stops short of full completeness because it does not differentiate from AME-related siblings like start_batch_encode or get_render_queue_status.

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 schema already documents output_path and preset_path clearly. The description adds no parameter-level detail, 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 names a specific verb ('request'), resource ('Adobe Media Encoder render-queue handoff'), and scope ('active sequence'), which distinguishes it from export_sequence, encode_file, and get_render_queue_status. It is not a tautology and tells an agent what the tool accomplishes.

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 active-sequence scope implies the tool is for handing off the current sequence, but there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named among AME-related siblings. The verification note is behavioral advice, not usage routing.

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?

Annotations provide little behavioral context beyond generic false hints, so the description carries the burden. It adds useful behavior beyond a mere insert by promising to verify that Premiere did not create unexpected same-track fragments. This is meaningful, though it does not detail failure modes, permission needs, or what happens when unexpected fragments are found.

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 sentence with no redundant wording. Both clauses add value: the core operation and the verification behavior. It is front-loaded and easy to parse.

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 a complete parameter schema and an output schema present, the description supplies enough for basic invocation and clarifies an important post-condition. It does not explain what timeline is targeted (e.g., active sequence) or characterize the verification outcome, leaving minor contextual gaps.

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?

Parameter schema coverage is 100%, with each parameter already described in the input schema. The description adds no additional parameter semantics or usage details, so a baseline score 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 a specific action ('Insert a project item at a timeline position') and adds a distinctive verification responsibility ('verify Premiere added no unexpected same-track fragments'). This makes the tool's purpose understandable and somewhat distinguishable from siblings like add_to_timeline_batch, though it does not explicitly name any 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?

The description implies when to use the tool: when a project item needs to be placed on the timeline. However, it gives no explicit guidance about prerequisites, when not to use it, or how to choose between this and closely related sibling tools such as insert_from_source or add_to_timeline_batch.

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 adds significant behavioral detail beyond the minimal annotations: all items and tracks are preflighted before the first insertion, every placement is read back, and the tool fails closed if verification fails. This clearly conveys atomicity and validation behavior, which is highly valuable for an agent deciding whether to invoke a mutating operation.

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, each earning its place: the first states the operation and batch limit, the second states the key validation and failure behavior. Information is front-loaded and there is no redundant 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 that an output schema exists, return values do not need to be described. The description covers batch size, validation semantics, read-back verification, and fail-closed behavior, while the schema fully covers parameters. No critical operational context is missing for an agent to invoke this 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 description coverage is 100%, so the schema already documents the clips parameter and its sub-fields comprehensively. The description adds behavioral context about preflight and verification, but not new parameter-level meaning beyond what the schema provides. Baseline 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 clearly states a specific action ('Insert up to 32 project items in one validated CEP request') and names the resource. It does not explicitly contrast itself with the similar sibling add_to_timeline, but the batch scope and item cap make its purpose 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?

The description implies use for batch insertion via 'up to 32' and 'one request', and references same insert-edit semantics via the schema, but it does not explicitly state when to prefer this tool over add_to_timeline or when not to use it. Usage context 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?

Annotations already indicate this is a mutating, non-idempotent operation. The description adds one useful behavioral disclosure: the tool returns an error if Premiere cannot add the exact requested count. It does not mention side effects on existing tracks, reversibility, or any other operational details, leaving this at a moderate level.

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 short sentences, front-loaded with the action and target, with no filler. The error guarantee is a valuable second sentence that earns its place. The word 'verified' is slightly ambiguous but does not undermine the conciseness.

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 tool with an output schema, the description is largely sufficient: it names the active sequence as context and the exact-count error condition. The only notable gap is the lack of differentiation from the similar-sounding 'add_tracks' sibling, and some ambiguity around what 'verified' means.

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 parameters are already well-documented by the schema. The description adds no additional meaning beyond restating that video or audio tracks are supported, which mirrors the track_type enum. Baseline 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 states a specific action ('Add'), a clear resource ('video or audio tracks'), and a target context ('active sequence'). It does not, however, distinguish itself from the sibling tool 'add_tracks', which appears to serve a very similar 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?

The description provides no guidance on when to use this tool versus alternatives such as 'add_tracks', 'create_caption_track', or track manipulation tools. The error-handling note implies exact-count behavior, but no explicit selection criteria or exclusions are given.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description reveals meaningful behavioral details: it verifies the result after adding, and it explicitly reports the edge case where QE inserts tracks at index 0 and shifts existing tracks up. This gives the agent important expectations about output behavior and side effects that annotations alone do not convey.

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 dense sentence that front-loads the main action, then states the verification requirement and the notable edge-case reporting behavior. Every clause earns its place; there is no filler or 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?

Given that an output schema exists and annotations already establish the mutation/non-destructive nature, the description provides all necessary operational context: what to do (add tracks), where (active sequence via QE), what to confirm (exact counts), and what to report (index-0 insertion). Nothing essential for invoking 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?

Input schema coverage is 100%, with clear descriptions for each numeric parameter (audio_tracks, video_tracks, audio_51_tracks, audio_mono_tracks). The description only refers generically to 'video and/or audio tracks' and 'requested counts', adding no parameter-specific meaning beyond what the schema already documents. Baseline 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 identifies the action ('Add video and/or audio tracks through QE'), the target resource ('the active sequence'), and the expected outcome ('gained the exact requested counts'). It goes beyond a simple restatement by adding verification and reporting behavior, making it easy to distinguish from sibling tools like add_track or add_to_timeline.

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 that this tool is for adding tracks to the active sequence, with specific requested counts, and emphasizes verification as part of the operation. It does not explicitly state when to prefer this over alternatives such as add_track, so it stops short of full exclusion 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?

Annotations already indicate this is a non-read-only, non-idempotent mutation, and the description adds little behavioral detail beyond that. The 'Uses QE DOM' note is an implementation detail rather than a useful behavior such as overwriting an existing transition or requiring handles around the cut.

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 short and front-loaded with the key action. The second sentence ('Uses QE DOM.') is an opaque implementation note that does not clearly earn its place but does not seriously harm 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?

For a straightforward four-parameter tool with an output schema and annotations, the description is minimally sufficient. It is incomplete in that it never disambiguates from the similarly named add_transition_to_clip and gives no indication of prerequisites such as having an actual cut point.

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 parameters are already documented. The description adds only the contextual notion of placing a transition at a cut point, which does not materially extend the schema's 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 uses a specific verb ('Add'), a clear object ('video transition'), and precise placement ('between two clips at a cut point'), so the core purpose is evident. It does not explicitly contrast with the similarly named sibling add_transition_to_clip, so sibling differentiation is incomplete.

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 the tool is for applying transitions at cuts, which gives a general context for use. However, it provides no explicit guidance on when to prefer this tool over add_transition_to_clip or batch_add_transitions, or what conditions would make it unsuitable.

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?

Annotations already signal a non-readonly, non-idempotent mutation. The description adds the core behavioral detail that the transition is applied to the clip's start or end. It does not disclose whether an existing transition is replaced, whether duration is clamped, or any other side effects, but there is no contradiction with 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 a single front-loaded sentence with no filler. Every word contributes to identifying the action, the target, and the location of the change.

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 schema and output schema carry most of the operational detail, and the description covers the core intent of adding a transition to a specific clip. The main gap is explicit disambiguation from sibling tools like add_transition and batch_add_transitions, but the 'specific clip' wording partially fills that.

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 fully describes all four parameters, including the position enum and default values. The description mostly paraphrases the schema ('start or end', 'specific clip') without adding meaning beyond what is already structured.

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 ('add') and resource ('specific clip's start or end'), making it clear the operation targets a single clip. It implicitly distinguishes itself from batch or generic transition tools by emphasizing 'specific clip', though it does not explicitly name a sibling 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?

The description provides no explicit guidance on when to use this tool instead of alternatives like add_transition or batch_add_transitions. It also omits prerequisites such as whether the transition name must be from the available transitions list or how the current selection relates to the node_id.

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?

Annotations already establish readOnlyHint=false (a write) and destructiveHint=false (non-destructive), so the safety profile is covered. The description adds useful scoping context by confirming it targets only the Level property and does not read or modify Amplify automation. It does not disclose clamping behavior, keyframe interaction, or whether the value takes effect immediately, but for a simple setter this is adequate.

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 short sentences with zero filler. The primary action ('Adjust a clip's Volume > Level in dB') is front-loaded, and the exclusion sentence earns its place by preventing a common misuse. Nothing could be removed without losing 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?

For a simple two-parameter setter with a fully documented schema, an existing output schema, and annotations covering the write profile, the description covers the essentials: what is set, in what unit, and what is deliberately out of scope. The only notable gap is the missing routing guidance relative to set_clip_volume, which an agent might reasonably confuse with 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?

Schema description coverage is 100%: node_id is documented as 'Node ID of the audio or video clip' and level_db is documented with units and direction ('0 = unity, negative = quieter, positive = louder'). The description's mention of 'in dB' only restates what the schema already provides. Per the high-coverage baseline, 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 states a specific verb ('Adjust'), a precise resource ('a clip's Volume > Level'), and the unit ('in dB'), making the operation unambiguous. The second sentence clarifies what it does not touch (Essential Sound Amplify automation), which narrows scope further. However, it does not explicitly differentiate itself from the sibling tools set_clip_volume and set_clips_volume, which appear to overlap in 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?

The Essential Sound Amplify exclusion implies a boundary: use this for the clip's Volume > Level property, not for Amplify automation. But no alternative tool is named, and the description gives no explicit 'use X when...' guidance for the closely related volume siblings (set_clip_volume, set_clips_volume). Usage context is implied rather than stated.

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 adds valuable behavioral context beyond the annotations: it is deterministic, never calls a model, never persists transcript text, and never changes Premiere. These statements meaningfully expand on the readOnly and idempotent hints and directly address likely concerns about side effects and model dependence.

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 short sentences carry the entire definition: the first states the core function and inputs, the second states key exclusions. There is no filler, and the most decision-relevant information 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 rich input schema, the existing annotations, and the presence of an output schema, the description is complete enough for an agent to select and invoke the tool correctly. It communicates the operational constraints and data dependencies without needing to repeat schema details or return-value 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?

The schema already documents all parameters at 100% coverage, so the baseline is 3. The description adds extra semantic value by emphasizing that segments are caller-supplied and revision-bound, and that silence ranges are optional and local, which clarifies the caller's responsibilities and the intended data flow.

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 ('Analyze') and a precise resource ('caller-supplied, revision-bound transcript segments and optional local silence ranges'), with a clear output concept ('deterministic dialogue-edit candidates'). It also separates itself from model-driven or mutating tools by stating what it never does, which helps distinguish it from 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 gives clear context for when to use the tool: when the caller already has normalized transcript segments and optional silence data and wants deterministic analysis. It does not explicitly name sibling alternatives or state when not to use it, but the 'caller-supplied' and 'never calls a model' phrasing implies the boundary well.

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 the tool's non-mutating scope beyond what the annotations provide: no audio normalization and no changes to the Premiere project, which is valuable safety information for an agent, especially since the annotations carry only negative hints (readOnlyHint=false, idempotentHint=false). There is a minor tension between 'Analysis only' and readOnlyHint=false, but the specific caveats prevent it from being a hard contradiction.

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 with zero filler: the core function and measurement units are front-loaded, and the critical 'analysis only' caveat lands immediately after. 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?

With an output schema present and full parameter coverage, the description only needs to cover selection criteria and side effects, which it largely does. Missing: no explicit guidance on choosing between media_path and project_item_id when both are provided, and no explicit routing to normalize_loudness_file or verify_delivery_file — minor gaps for an otherwise complete definition.

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 documents all 5 parameters at 100% coverage, so the schema carries the documentation burden and the baseline of 3 applies. The description connects to measurement outputs (LUFS/LU/dBFS) but adds no syntax, format, or relationship details about parameters like target_lufs or tolerance_lu beyond what the schema already states.

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 ('Measure') with precise resources: integrated loudness (LUFS), loudness range (LU), and true peak (dBFS) from a local media file via FFmpeg's EBU R128 filter. The closing clause explicitly distinguishes it from the mutating sibling normalize_loudness_file, so an agent can tell them apart at a glance.

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 a clear exclusion — 'it does not normalize audio or change Premiere' — which tells the agent this is the wrong tool for normalization or project-modification tasks. However, it doesn't explicitly name the alternative (normalize_loudness_file) or offer affirmative when-to-use guidance relative to nearby siblings like verify_delivery_file.

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 explicitly claims the operation is 'Read-only', but the annotations set readOnlyHint to false. This is a direct contradiction that makes the safety profile unreliable. The description otherwise adds only the use of FFmpeg idet, which is method detail, not behavioral disclosure such as side effects, permissions, or resource implications.

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 filler, and the classification output is front-loaded. Every word earns its place, apart from the problematic 'Read-only' claim which hurts accuracy more than structure.

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 schema covers parameters and an output schema exists for return values, so those do not need elaboration. However, the direct contradiction between 'Read-only' and readOnlyHint=false leaves the tool's behavior profile untrustworthy, and there is no guidance on when to use this tool versus sibling quality-control or inspection tools. These gaps make the definition incomplete for safe autonomous 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?

The input schema already provides 100% parameter coverage: media_path is described as an existing local video file, and sample_seconds is fully documented with range and default. The description adds little parameter-level meaning beyond clarifying that the sample duration applies to decoded frames, 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 states a specific verb ('classify'), a specific resource ('decoded video frames'), the possible classification outputs (progressive, top-field-first, bottom-field-first, mixed, undetermined), and the method ('using FFmpeg idet'). It also frames it as a delivery preflight, which distinguishes it from general analysis or encoding tools. This is a model of purpose clarity.

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 'Read-only delivery preflight' gives clear context that this is a pre-check, not an edit or export operation. However, it does not name sibling alternatives like analyze_video_qc or inspect_media_streams, nor does it state when this tool should be chosen over them. Clear context but no explicit 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 explicitly claims 'Read-only: it does not contact Premiere or modify the file,' but the annotations set readOnlyHint=false. This is a direct contradiction between the described behavior and the structured metadata, so the agent cannot reliably trust the tool's side-effect profile.

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 and every sentence earns its place: the first states the operation and target, the second clarifies the safety profile. There is no filler, title repetition, or schema 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 simple three-parameter tool with a full input schema and an output schema, the prose covers the main non-schema context: local file, FFmpeg, black/freeze detection, and no Premiere modification. The annotation contradiction slightly undermines overall completeness, but the prose alone is nearly sufficient 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 schema already documents all three parameters. The description's reference to a 'local video' aligns with media_path but adds no additional meaning, and the black/freeze thresholds are fully covered by the input 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 names a specific action ('Analyze'), a specific input ('local video delivery'), specific targets ('sustained black and frozen sections'), and the method ('FFmpeg'). This makes the tool's purpose unmistakable and distinguishes it from sibling analyzers such as analyze_video_interlacing or inspect_media_streams.

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 useful context that this is for local file QC and does not require Premiere, so an agent can infer when to use it. However, it does not explicitly state when not to use it or name alternative tools for related QC checks, so usage guidance is implied rather than fully 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?

Beyond the annotations, the description discloses several important behaviors: it requires confirmation, consumes the token before dispatch, rechecks hosts and file metadata, and explicitly does not save, render, or change a timeline. These details give the agent an accurate model of side effects and safety, and they do not contradict any annotation.

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 tightly written sentences with no filler. The primary action is front-loaded, followed by required preconditions and explicit non-behaviors. 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?

For a two-parameter tool with full schema coverage and an output schema, the description covers the essential preconditions, constraints, and exclusions an agent needs. It clearly explains the token requirement and confirmation flow, leaving no critical gap for invoking 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 input schema already has 100% coverage, documenting preview_token and confirm_import clearly. The description adds the behavioral note that the token is consumed before dispatch, which reinforces the one-time nature, but it does not add substantial new 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: 'Import exactly one previewed completed AE render into its approved Premiere bin.' It also names the destination and unique constraints (exactly one, previewed, approved), which clearly separates this apply step from the sibling preview tool and other After Effects import 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 implies when to use this tool by referencing a previewed render and requiring a confirmation token from the preview step. It also clarifies boundaries with 'Does not save, render, or change a timeline.' However, it does not explicitly name the alternative preview tool or state a when-not-to-use condition.

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?

Annotations already communicate mutability (readOnly=false) and non-destructiveness; the description adds a small behavioral detail: QE catalog lookup with a fallback exact-name probe when enumeration is empty. It still does not explain side effects, error behavior, or what happens when the exact-name probe fails, so it is only mildly additive.

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 with no fluff. The main action is front-loaded, and the technical QE note is separated and kept brief.

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 an output schema and mutation annotations, the description is mostly adequate. However, it relies on the unexplained acronym 'QE', omits how an agent should enumerate valid effect names, and provides no usage context versus the many effect-related 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 coverage is 100%, so the schema defines node_id and effect_name. The phrase 'exact-name QE probe' adds some meaning to effect_name by implying an exact catalog name is needed, but the description lacks detail on where that catalog comes from. This remains near the baseline 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 states a specific verb, applying an audio effect to a clip, and identifies the resource type. This clearly differentiates it from the sibling apply_effect and list_available_audio_effects without requiring schema inspection.

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 when-to-use guidance is provided, nor any exclusion against apply_effect or suggestion to consult list_available_audio_effects for valid effect names. The only usage-related detail is an internal QE fallback, which does not help an agent choose among 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description adds genuine behavioral context: it revalidates every target before acting, requires the edit capability, and is gated by an exact confirmation token. None of these details are expressed by the annotations, and the description does not contradict them.

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 with no filler: the first states the action and the key behavioral detail (revalidation), the second states the preconditions (capability and token). Everything earns its place and 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 compound edit with revalidation and token gating, the description covers the core workflow, prerequisites, and safety behavior, while the output schema handles return values. The main uncovered gap is failure behavior (what happens when revalidation or token verification fails), but the essentials are all 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?

Schema coverage is 100%, so the schema already documents both parameters thoroughly, including the plan structure and the token's origin in preview_edit_plan. The description reinforces the confirmation_token semantics ('exact token') and the plan's compound-edit nature, but adds little meaning beyond the schema, matching the baseline for high 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 uses a specific verb-resource pair ('Apply a previously previewed compound edit') and adds distinguishing scope: revalidation and the confirmation-token gate. It clearly separates this commit-step tool from siblings like preview_edit_plan, create_context_edit_plan, apply_spot_workflow_plan, and apply_mogrt_premiere_handoff.

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 'previously previewed' phrasing and the requirement for an 'exact preview confirmation token' make the preview-then-apply workflow evident, and the capability requirement signals when the tool is permitted. However, it does not explicitly name preview_edit_plan as the prerequisite or state when not to use this tool, leaving some inference to the agent.

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 adds meaningful behavioral context beyond the annotations by disclosing the QE DOM catalog lookup and the exact-name QE probe fallback when catalog enumeration is empty. It does not contradict the readOnlyHint=false, destructiveHint=false, or idempotentHint=false 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 two sentences, front-loads the core purpose, and keeps implementation detail in a separate clause. It is appropriately sized, though 'QE' is used without expansion, which slightly reduces clarity for unfamiliar readers.

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 tool with a fully covered schema and an output schema, the description is reasonably complete. It explains the main action and a fallback behavior, though it does not explicitly mention an effect must already exist or how failures are surfaced.

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 fully documents both parameters with 100% coverage, giving a baseline of 3. The description adds extra meaning by noting that effect_name is matched via an 'exact-name QE probe' in fallback conditions, which clarifies matching behavior 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 verb and resource: 'Apply a video effect to a clip.' It distinguishes itself from sibling tools like apply_audio_effect by specifying 'video effect,' and the effect_name examples make the intent 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 for video effects but does not explicitly say when to choose this over apply_audio_effect, list_available_effects, batch_apply_effect, or remove_effect. No when-not or alternative guidance is stated, only an internal implementation note.

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?

Annotations already indicate this is not read-only and not idempotent. The description adds the behavioral detail that the LUT is applied through Lumetri Color, but it does not explain whether an existing Lumetri effect is replaced, how the modification is applied, or any 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 a single, front-loaded sentence with no filler. Every word adds meaning: what is applied, to what, and through which mechanism.

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 tool with full schema coverage, an output schema, and annotations, this description is nearly complete. It is slightly light on prerequisites or expected behavior around existing Lumetri effects, but the core call is adequately specified.

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 'node_id' and 'lut_path' documented. The description mainly restates the LUT concept already in the schema and does not add meaningful parameter semantics beyond 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?

The description states a specific verb ('Apply'), a specific resource ('a LUT file'), and the target ('a clip') via a specific method ('Lumetri Color'). This clearly distinguishes it from generic color correction or effect-applying tools in the 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?

The description gives no explicit guidance about when to use this tool versus siblings like 'color_correct' or 'apply_effect'. It implies usage through the resource type, but does not state alternatives or conditions.

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 annotations already convey non-read-only and non-destructive traits, but the description adds valuable behavioral context beyond them: it targets a 'disposable' verification sequence, imports into an 'empty track,' requires explicit confirmation, and explicitly disclaims any rendered-frame guarantee. It does not elaborate on failure modes or side effects, but the guidance is materially richer than the raw 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 two sentences with no wasted words. It front-loads the primary action ('Import exactly one previewed MOGRT'), then adds the follow-up read-back and the two critical caveats (explicit confirmation and no rendered-frame claim). Every sentence contributes essential operational 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?

An output schema exists, so return descriptors need not be enumerated. The description covers the target sequence, track state, quantity, confirmation requirement, and a key limitation. It does not explicitly connect to the preceding preview step by name, but the schema's preview_token reference fills that gap. Overall, it is sufficiently complete for a specialized apply step.

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 parameters preview_token and confirm_import are already fully described in the input schema. The tool description adds no new parameter-specific detail beyond the general mention of 'explicit confirmation,' which aligns with confirm_import. With the schema handling the heavy lifting, a 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 states a specific verb ('Import'), a specific resource ('exactly one previewed MOGRT'), and a precise destination ('empty track of the explicit disposable Premiere verification sequence'). It also clarifies follow-up action ('read back insertion and control descriptors') and distinguishes this from preview by requiring a 'previewed' MOGRT and explicit confirmation. This is a clear, non-tautological statement of the tool's 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?

The description clearly implies this is the apply step after a preview, via 'previewed MOGRT' and the one-time preview_token requirement in the schema. It also states the important precondition of 'explicit confirmation.' However, it does not name sibling alternatives (e.g., preview_mogrt_premiere_handoff or apply_after_effects_render_handoff) or state when not to use this tool, so it falls short of a full routing guide.

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 annotations provide only generic false hints, so the description carries the behavioral burden and does so strongly. It discloses that applying requires edit authority, that a MOGRT plan requires filesystem authority, that only empty explicitly named tracks are targeted, and that 'host readback is not playback or render verification.' These are non-obvious, high-value behavioral facts beyond what annotations or schema provide.

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, purposeful sentences with no filler. The core action is front-loaded, the constraints follow immediately, and the verification caveat closes the description. 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?

For a 2-parameter tool with an output schema, the description covers the core prerequisites, the empty-track-only constraint, and the important readback limitation. It does not explicitly step through the full 'preview first, then provide both returned values' flow, but that is recoverable from the schema descriptions and the word 'previewed.'

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 reinforces that the plan is exact and previewed and lists the relevant plan types, but it does not add substantial parameter-level meaning beyond what the input schema already states for plan and confirmation_token.

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, 'Apply,' and names an exact resource: 'one exact previewed motion-demo, product-spot, or brand-spot plan.' This clearly distinguishes the tool from the many preview_*_spot and apply_* siblings and tells an agent exactly what this tool consumes.

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 that the tool is only for plans generated by a matching preview tool, and it states important conditions: requires edit authority, requires filesystem authority for a MOGRT, and only targets empty explicitly named tracks. It does not explicitly name sibling alternatives such as apply_edit_plan or state when not to use this tool, so exclusion guidance is implied rather than fully spelled out.

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?

Annotations already indicate a write operation (readOnlyHint=false) and non-destructive behavior. The description adds useful behavioral detail: it confirms the property against the sequence project item's XMP packet and reports failure when the property does not land in XMP. This goes beyond the annotations without contradicting them.

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 action and target, followed by a concise note about failure reporting. Every sentence contributes necessary information 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 simple two-string-parameter write operation with full schema coverage, an output schema, and safety annotations, the description provides enough operational and verification context. An agent can select and invoke this tool correctly without additional clarification.

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 both required parameters are fully documented in the input schema. The description only paraphrases them as 'key/value pair' and does not add meaningful semantic detail beyond what the schema already provides.

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, 'Attach a custom property (key/value pair)', and names the target, 'the active sequence', plus the XMP confirmation. This clearly distinguishes it from metadata-related siblings like set_metadata and set_xmp_metadata.

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 context for the operation, namely attaching to the active sequence and verifying against the XMP packet, but it does not name alternatives or state when not to use this tool. Usage guidance is therefore 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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, and the description adds concrete guarantees: 'Local-only' and 'never changes Premiere.' It also discloses output shape (score, timecoded findings, fix routes), which helps the agent set expectations beyond the annotation flags.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence front-loads the verb and resource, then packs the audit categories and output. No filler or repetition of schema content; every clause adds 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 tool is complex with a nested snapshot object, 7 parameters, and an output schema, but the description covers the main behavior, categories, and guarantees. With rich input and output schemas present, nothing required for correct 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 description coverage is 100%, so the input schema already documents all parameters and nested snapshot shapes. The description adds no parameter-level detail, so the rubric 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 states a specific verb ('Audit'), a precise resource ('one sequence snapshot'), and enumerates the full set of checks it performs (flash frames, gaps, overlaps, disabled clips, etc.). This is specific enough to distinguish it from siblings like diff_sequence_snapshots or get_timeline_gaps without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use this when you have a sequence snapshot and need a read-only health audit with a score, findings, and fix routes. It does not explicitly name alternatives or state when not to use it, 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?

The description adds little beyond the title and does not disclose key behaviors such as whether a new sequence is created, whether the original sequence is modified, or that Auto Reframe performs analysis. Annotations are present but only provide generic false hints; the description does not enrich them.

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. It is appropriately concise, though it could use the saved space to mention side effects or creation behavior.

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 schema covers parameters and an output schema exists, so an agent can likely invoke the tool correctly. However, the description omits important contextual information such as whether a new sequence is created and what happens to the original sequence, making it only minimally viable.

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 all six parameters are documented. The description only loosely contextualizes the target dimensions as an aspect-ratio change, which adds minimal meaning beyond the schema's explicit 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 names a specific action ('Auto-reframe'), a resource ('a sequence'), and the purpose ('for a different aspect ratio'). It is clear on its own, but it does not explicitly differentiate from similar sequence-creation or sequence-modification siblings such as create_sequence or set_sequence_resolution.

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 alternatives, and no mention of prerequisites or situations where another tool would be more appropriate. The intended use is only implied by the action described.

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?

Annotations show destructiveHint=false but idempotentHint=false, so it's not clearly marked safe from repeated calls. The description doesn't disclose whether it overwrites existing transitions, whether it targets only clip-to-clip cuts (excluding gaps), or what happens with the default track_index=0.

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?

One sentence, zero filler, and the key behavior ('same transition to all cut points on a track') is front-loaded. This is an ideally compact definition.

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?

As a simple batch version of an existing sibling operation, it is mostly complete; the output schema exists and parameters are well documented. The main gap is not saying whether existing transitions at cut points are replaced or skipped, which matters for idempotent 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?

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds the contextual meaning of applying the same transition to all cut points but doesn't clarify effective defaults 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 ('add') and resource ('transition to all cut points on a track'), clearly distinguishing it from the sibling tools add_transition and add_transition_to_clip. It states the scope: all cut points on a track, not a single 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?

The context makes it clear this is for batch/bulk transition application across cut points, implicitly distinct from the single-transition siblings. However, it doesn't explicitly state when to prefer it over add_transition or add_transition_to_clip, or mention the track_index default.

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 reveals behavior beyond the annotations: targets are preflighted and verified via component-count readback, and non-compatible targets are excluded. This adds meaningful operational context, while the annotations already signal a mutating, non-idempotent operation; no contradiction.

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, front-loaded with the action and scopes, with the verification detail in the second sentence. No filler or repetition of schema/annotations.

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 plus a 100%-described schema covers the main operational decisions: target selection, track requirements, and effect name. Since an output schema is present, the lack of return-value detail is not a gap; only alternative routing and exact behavior on incompatible clips are left implicit.

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 four parameters at 100% with descriptions. The description adds little param-level meaning, only the compatibility filter and the one-effect constraint, so baseline 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?

Description opens with a specific verb–resource pair ('Apply one audio or video effect') and enumerates the three target scopes. It clearly differentiates this batch tool from single-target siblings like apply_effect/apply_audio_effect by the target set and the word 'compatible'.

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 states exactly when to use it: to apply a single effect across selected clips, an entire compatible track, or all compatible clips. It does not name alternative tools or say when not to use it, but the scope is clear enough to route an agent.

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 annotations are all false-valued (not read-only, not idempotent, not destructive) and thus carry almost no safety context, leaving the burden on the description. The description only restates the core operation and adds no detail on prerequisites (e.g., active sequence, non-empty selection), failure conditions, or effects on locked/unselected clips. For a mutating tool this is a significant behavioral 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 — verb, resource, and scope all appear near the front. The only minor redundancy is that 'multiple clips at once' echoes the title's 'Batch' concept, but this is acceptable reinforcement rather than waste.

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 4-parameter tool with full schema coverage and an output schema present, the description conveys the core purpose adequately. It does not, however, mention the alternative singular tool, prerequisites for each target mode, or edge-case behavior (empty selection, locked tracks), which an agent would need to invoke it reliably among 180+ siblings. Adequate but with clear gaps.

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 all four parameters (target, enabled, track_type, track_index) are already documented, including the conditional requirement for track_type/track_index when target is 'track'. The description's parenthetical '(selected, track, or all)' merely restates the target enum and adds no new semantic meaning. Baseline 3 applies given full 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 states a specific verb ('Enable or disable'), a resource ('multiple clips'), and the targeting scope ('selected, track, or all'). The phrase 'multiple clips at once' distinguishes it from the sibling enable_disable_clip, which handles the singular case. This is immediately actionable and clearly differentiated.

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 targeting modes ('selected, track, or all') give a clear sense of when this tool applies to batch operations. However, it never names the singular sibling enable_disable_clip as the alternative for single-clip toggles, nor does it state when NOT to use it (e.g., for muting audio or locking tracks). Usage 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?

Annotations already indicate this is a write operation and not idempotent. The description adds the context that it renames clips on a timeline and supports sequential numbering, but does not disclose side effects such as whether source media files are left untouched or whether re-running is safe. Given the annotation coverage, this is adequate but not rich.

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 adds meaningful context about what the tool does and the pattern capability it supports.

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 a complete input schema, useful annotations, and an output schema present, the description is largely sufficient for correct invocation. It covers the batch nature and pattern behavior. The main gap is lack of explicit guidance about when to choose this over rename_clip, but that is a usage-nuance rather than a blocking omission.

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 all parameters are already documented in the input schema. The description mentions pattern and sequential numbering, which lightly echoes the pattern schema, but it does not meaningfully add beyond what the schema provides. Baseline 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 states a specific verb ('Rename') and a specific resource ('multiple clips on the timeline') and adds the pattern-based renaming mechanism. This clearly differentiates it from sibling singular tools like rename_clip and rename_bin/rename_project_item.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.