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 mutating operation (readOnlyHint=false), so the description adds little beyond the basic action. It does not disclose whether existing keyframes are replaced or appended, whether keyframes must be sorted by time, or what constraints apply to level_db. No contradiction with annotations exists, but the behavioral detail is thin.

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 states the action and the purpose in the fewest possible words while remaining informative.

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 both parameters and an output schema exists, so the basic call is well specified. However, the lack of usage guidance and missing behavior around existing keyframes leaves the definition incomplete for an agent deciding when to call it and what side effects to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema fully documents node_id and the time_seconds/level_db keyframe properties. The description adds no parameter-level meaning beyond the schema, so the 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 uses a specific verb-resource pairing: 'Add audio level keyframes', and it states the intended purpose ('create fades or level changes'). This clearly distinguishes it from generic add_keyframe and from one-shot level adjustment tools like 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?

No guidance is given for when to use this tool versus alternatives such as add_keyframe, adjust_audio_levels, set_clip_volume, or setup_ducking. The phrase 'to create fades or level changes' implies a use case, but there are no explicit conditions, exclusions, or alternative recommendations.

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 adds critical behavioral context: this tool is not a functional implementation and should not be expected to perform the named operation. It also explains the underlying platform limitation. It stops short of stating precisely what happens if the tool is invoked (e.g., returns an error), but the 'Unavailable' disclosure is strong.

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 one tightly written sentence that front-loads the critical 'Unavailable' signal, then gives the reason and actionable alternatives. Every word earns its place; there is no filler or redundancy.

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

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

For an unavailable/stub tool, the description is complete: it states the limitation, names the correct alternative path, and provides a secondary option for title graphics. The presence of an output schema reduces the need to describe return values, and nothing essential is missing for an agent deciding whether to call 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%, so all four parameters are already documented with meaningful descriptions. The tool description adds no additional parameter-level semantics, which is acceptable here because the tool is declared unavailable and the agent is redirected to alternatives.

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 immediately and unambiguously states that this tool is unavailable for its nominal purpose, with a specific reason: Premiere exposes no supported API for creating caption clips from raw text. This clearly distinguishes it from related tools like create_caption_track without requiring the schema to be opened.

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

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

The description explicitly tells the agent what to do instead: import an .srt/.vtt and use create_caption_track, or use a MOGRT/PNG overlay for title graphics. It provides both a direct alternative and a fallback, leaving no ambiguity about when or whether to call 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 declare readOnlyHint=false and idempotentHint=false, so the description adding 'add ... to ... render queue' is consistent. However, it does not disclose side effects like whether this launches AME, blocks until encoding, or merely queues the item. Since annotations exist but are sparse, some additional behavioral context would be valuable.

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, clear sentence with no filler. It could arguably name the sibling alternative for disambiguation, but it is appropriately concise and front-loaded.

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

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

For a tool with two optional-style parameters (one required) and an output schema, the description is minimally sufficient. However, it does not explain what happens when preset_path is omitted, how the output_path should be formatted, or what the return value represents, leaving some ambiguity.

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 output_path and preset_path are already documented in the schema. The description itself does not add further meaning beyond what the schema provides, which meets the baseline but does not exceed 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 clear, specific verb ('add') and resource ('active sequence to the Adobe Media Encoder render queue'). It is distinguishable from siblings like start_batch_encode, export_sequence, and encode_project_item because it specifically targets the AME render queue.

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 operates on the active sequence and targets Adobe Media Encoder, but it does not explicitly state when to prefer this over export_sequence, encode_file, or start_batch_encode, nor does it mention prerequisites like having AME installed or an active sequence being required.

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 discloses meaningful behavior beyond the annotations: preflighting before first insertion, read-back verification of every placement, and fail-closed behavior if Premiere cannot verify one. This gives the agent a clear model of how the tool behaves at execution time.

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

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

The description is two concise, front-loaded sentences covering purpose, limits, and failure behavior. It avoids filler and appropriately leaves parameter-level detail to the schema.

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

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

With full schema coverage, an output schema present, and annotations covering safety hints, the description provides the missing operational context: batch limit, preflight, read-back, and fail-closed behavior. No critical call-time decision is left unaddressed.

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 explains the individual parameters. The main description adds the undocumented 32-item limit and validation semantics, while the clips schema adds ordering and insert-edit constraints, providing extra value beyond the raw 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 ('Insert'), a specific resource ('project items'), and a clear scope ('up to 32 in one validated CEP request'). The 'batch' framing and the 32-item limit clearly distinguish it from the singular sibling 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 and clips schema point to add_to_timeline semantics, and 'up to 32' implies a multi-item batching use case. However, it never explicitly states when to choose this tool over add_to_timeline or what conditions would make the singular tool preferable.

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?

Annotations already indicate this is not read-only or idempotent, so the mutation is expected. The description adds useful behavioral context by stating that the tool verifies the active sequence's resulting track counts, which is a meaningful side-effect disclosure beyond the structured hints. 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 phrase earns its place: 'Add', 'video and/or audio tracks', 'through QE', and the verification clause.

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 four optional numeric parameters, full schema coverage, and the presence of an output schema, the description supplies the essential purpose and postcondition. It could clarify behavior when no active sequence exists or explicitly distinguish itself from add_track, but nothing critical is missing for invoking the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each of the four parameters already explained and given defaults. The description only summarizes them as 'video and/or audio tracks' and adds the verification behavior; it does not provide additional parameter-level meaning. This matches the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Add'), the resource ('video and/or audio tracks'), the mechanism ('through QE'), and a clear postcondition ('verify the active sequence gained the exact requested counts'). It is easily distinguished from the singular sibling add_track and from delete_track or create_caption_track.

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

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

The description implies when to use it: when you need to add multiple track types and confirm the active sequence has the exact counts. However, it does not explicitly route away from add_track or state any exclusions or prerequisites, so the usage guidance is left mostly to inference.

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?

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?

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?

The description discloses meaningful behavioral context beyond the annotations: every target is revalidated before applying, the edit capability is required, and an exact preview token is mandatory. It does not describe failure behavior or atomicity, but the annotations include no positive safety hints, so the description carries the burden well enough.

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 tight sentence that front-loads the core purpose, then adds the two most important constraints: revalidation and the token requirement. There is no filler or repetition.

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

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

The description, combined with full schema coverage and an output schema, gives an agent the essential purpose, precondition, permission requirement, and token requirement. It is slightly incomplete regarding what happens when revalidation fails, but that is a minor gap for a two-parameter apply operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents plan and confirmation_token. The description reinforces that the token is exact and that the plan was previewed, but it adds little semantic meaning 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 uses a specific verb ('Apply') with a clear resource ('previously previewed compound edit') and adds the key precondition of revalidation. It is immediately distinguishable from preview_edit_plan and other workflow-plan siblings because it applies, rather than creates or previews, a plan.

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 this tool is used after a preview step and requires an exact confirmation token, which routes the agent toward preview_edit_plan as the prerequisite. However, it does not explicitly name the sibling or spell out when not to use it, so it stops just short of full routing guidance.

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

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

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?

Annotations establish that this is a non-read-only, non-idempotent mutation, and the description adds valuable behavioral context: required authorities, the restriction to empty explicitly named tracks, and the warning that host readback is not playback or render verification. No contradiction with annotations is present.

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

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

Three dense sentences cover purpose, constraints, and a critical verification caveat, with no filler. The most important action is front-loaded, and every sentence contributes meaningful 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?

Given the tool's complexity, the description covers the key preconditions: previewed exact plan, confirmation token, authority requirements, track targeting, and verification limitations. The output schema handles return-value expectations, and the main gap is a lack of explicit tie-back to which sibling preview tools apply in which cases.

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 fully documents both parameters. The description reinforces that the plan must be "exact" and "previewed," but this largely echoes the schema's own wording rather than adding new semantic detail.

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 opening sentence uses a specific verb-resource pairing: "Apply one exact previewed motion-demo, product-spot, or brand-spot plan." This clearly distinguishes it from sibling tools like apply_edit_plan and the various preview_*_spot tools by naming the exact plan types it 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 conveys when to use the tool by requiring an "exact previewed" plan and confirmation token, which implies the preview_*_spot workflow must run first. It also gives practical constraints: edit authority, filesystem authority for MOGRT, and empty named tracks. It stops short of explicitly spelling out alternatives or when not to use the tool.

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

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

The annotations already communicate that this is a write operation, non-idempotent, and not destructive, so the description does not need to restate those. The description adds the target scope ('active sequence') but does not disclose behavior such as overwriting existing properties, requiring an active sequence, or failure semantics. This is acceptable but minimal.

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, compact sentence that front-loads the action, object, and target. There is no filler or redundant wording, and it is appropriately sized for a simple two-parameter tool.

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

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

For a tool with only two required parameters, an output schema, and annotations, the description is largely sufficient. The main gap is that it does not indicate where property_id comes from or how custom properties relate to metadata fields created by sibling tools, but this is not blocking for basic 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 provides 100% parameter description coverage, so the schema already documents property_id and property_value. The description's 'key/value pair' phrasing usefully reinforces how the parameters relate, but it does not add significant new constraints or formatting details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (attach), a specific resource (custom property as a key/value pair), and a specific target (the active sequence). This clearly distinguishes it from related metadata tools like add_custom_metadata_field or set_metadata without needing to inspect the schema.

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

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

No guidance is provided about when to use this tool versus related metadata/sequence tools, nor any prerequisites such as requiring an active sequence. The description implies the use case through the phrase 'active sequence,' but it does not explicitly route the agent away from alternatives or clarify 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 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.

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

The phrasing 'Rename multiple clips' implies it is for batch operations rather than single-clip renaming, but no explicit alternatives or when-not-to-use conditions are given. The description leaves the decision to inference rather than naming a sibling such as rename_clip.

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

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

With annotations providing only limited safety signals (readOnlyHint false, destructiveHint false), the description adds useful behavioral context by stating that the tool returns inline image data rather than writing to disk. It also communicates that this is an inspection aid for the LLM. It could disclose more about side effects or cost, but the core behavior is clear.

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 tight sentences, front-loaded with the action and outcome. Every sentence earns its place: the first states what happens and the second states the intended use case.

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 tool with one optional parameter, 100% schema coverage, no nested objects, and an output schema, the description is sufficient. It clearly explains the purpose, return form, and the scenario in which an agent would want to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single optional parameter time_seconds is fully documented in the schema (100% coverage), including its default behavior. The description adds no new parameter-level detail beyond reinforcing that the 'current frame' is the default, so the baseline schema coverage 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 names a specific action ('Capture the current frame') and delivers the key outcome ('return it as inline image data for the LLM to see'), which distinguishes it from sibling export/render tools like export_frame or freeze_frame. It clearly identifies the resource as the current timeline state.

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 second sentence gives clear context for when an agent should call it: when the AI needs to visually inspect the current timeline state. It does not explicitly name alternatives or say when not to use it, but the purpose is specific enough to guide selection.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the semantic clarification that 'offline' means 'missing.' It does not disclose the scope or nature of the check beyond what the annotations and output schema already imply.

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, front-loaded, declarative sentence with no wasted words. It is exactly the right size for a zero-parameter read-only check.

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

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

Given the tool's low complexity (no parameters, read-only, idempotent) and the presence of an output schema, the description is sufficient for correct invocation. The only meaningful gap is the ambiguity with get_offline_media, which is a usage-guidance issue rather than a completeness issue.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and schema description coverage is 100%, so there is nothing for the description to clarify about inputs. The baseline of 4 for zero-parameter tools 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 the action ('Check') and resource ('offline media'), and the parenthetical '(missing)' clarifies what 'offline' means. However, it does not distinguish this tool from the nearly identical sibling get_offline_media, so an agent cannot tell them apart from the description alone.

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 alternatives such as get_offline_media, get_used_media_report, find_items_by_media_path, relink_media, or refresh_media. The description leaves the agent to guess which tool is appropriate for a given situation.

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 mutation (readOnlyHint=false) that is not flagged destructive. The description adds genuine behavioral context beyond annotations: the operation resets the item to full duration, explaining the semantic consequence of clearing points. It doesn't discuss reversibility or effects on existing sequences, but the core behavior is disclosed and 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?

A single sentence with zero filler: verb, target, and outcome in one compact phrase. The behavioral clarification is delivered as a parenthetical that earns its place rather than padding the description.

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-param boolean operation with an output schema and full schema coverage, the description captures the essential semantics. Minor gaps: it doesn't orient the agent toward the closely related set_item_in_out and clear_sequence_in_out siblings, and the definition of 'project item' is left to the schema. These are small omissions for a low-complexity 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%, so the schema fully documents item_id, clear_in, and clear_out including defaults. The description adds the 'and/or' clarification and the 'reset to full duration' outcome, but no param-specific detail beyond what the schema already provides. Baseline 3 is appropriate when the schema carries the load.

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 (clear), a precise resource (in/out points on a project item), and the resulting state (reset to full duration). The parenthetical clarifies what 'clearing' actually means, and the phrase 'project item' distinguishes it from sequence-level siblings like clear_sequence_in_out and set_sequence_in_out_points.

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 resource scope ('on a project item') implies when the tool applies, and the sibling list contains sequence-level counterparts (clear_sequence_in_out, set_sequence_in_out_points) that an agent could infer are alternatives. However, no explicit routing, exclusions, or conditions are given — the agent must infer the boundaries between this tool and related item-level tools like set_item_in_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 signal a non-read-only, non-idempotent operation, so the description's job is lighter. It adds that the action targets in/out points on the active sequence and that either or both can be cleared, but it does not disclose recovery behavior, no-op behavior, or what happens if the sequence lacks in/out points.

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, front-loaded sentence with no redundant words. It efficiently states the operation, target, and scope.

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-optional-boolean tool with a full schema and output schema, the description plus schema are sufficient for an agent to invoke it correctly. No critical behavioral or contextual information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%: both clear_in and clear_out have descriptive text and defaults. The description's 'and/or' phrasing matches the boolean combination model, but it adds little beyond what the schema already communicates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('clear'), a precise resource ('the in and/or out points'), and a scope ('active sequence'). This cleanly distinguishes it from related tools like set_sequence_in_out_points and clear_item_in_out.

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

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

No guidance is provided about when to use this tool versus alternatives such as set_sequence_in_out_points, get_sequence_in_out_points, or clear_item_in_out. The intended invocation context is only implied by the phrase 'active sequence.'

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

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

With destructiveHint=true, readOnlyHint=false, and idempotentHint=false already in the annotations, the description adds no behavioral context: nothing about undo-ability, unsaved changes in clips, behavior when no clips are open, or whether project items are unaffected. The description is consistent with the annotations but contributes nothing beyond 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?

A single six-word sentence that carries full meaning with no filler. The core action and target are front-loaded and immediately parsable.

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 zero-parameter tool with an output schema and destructive annotation, the description is mostly adequate. However, it omits useful operational details such as the relationship to close_source_monitor, failure behavior when no clips are open (non-idempotent hint suggests calling it with an empty Source Monitor may error), and absence of impact on project bins.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and 100% vacuous schema coverage, which sets the baseline at 4. The phrase 'all clips' usefully signals that the operation is non-selective and cannot be scoped to an individual clip.

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 (close) and a clearly bounded resource ('all clips in the Source Monitor'). It distinguishes itself from the nearest sibling close_source_monitor, which targets the monitor panel itself rather than the clips within it.

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

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

No guidance is given on when to use this tool versus the closely related sibling close_source_monitor, or whether it complements open_in_source / set_source_in_out workflows. The agent must infer usage context from the name alone.

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 destructiveHint=true and readOnlyHint=false, so the description does not need to restate the destructive nature. It adds no further behavioral detail such as unsaved-changes handling, but the input schema's save_first parameter covers that, and the description does not contradict 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?

A single sentence that is direct and front-loaded: it names the action and target immediately. There is no filler or redundancy.

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

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

For a simple one-parameter destructive action, the description plus annotations and output schema cover the essential context. It does not discuss failure cases like no open project, but that is reasonably implied by 'current project' and is not a critical 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?

Schema description coverage is 100% and the single save_first parameter is self-explanatory in the schema. The tool description adds no parameter-specific detail, which is acceptable because the schema carries full semantic weight.

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 ('Close') and resource ('the current Premiere Pro project'), clearly distinguishing it from sibling tools like open_project, create_project, and save_project. The word 'current' adds necessary scope and prevents confusing it with closing a sequence or source 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 description makes the usage context clear: call it to close the active Premiere Pro project. It does not explicitly enumerate alternatives or when not to use it, but the action is distinct enough among siblings that the context alone is sufficient.

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 some context beyond the annotations by specifying that the tab (not the sequence data) is what gets closed, which mitigates confusion with delete_sequence. However, it does not elaborate on the destructive implications flagged by destructiveHint=true — e.g., whether unsaved state is lost or whether the sequence remains available after closing.

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, front-loaded sentence with zero filler. The core action ('Close a sequence tab') appears first, followed by the location ('in the timeline'), which is all the description needs.

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 one-parameter tool with an output schema and 100% schema coverage, the description covers the essential operation. The only notable gap is not clarifying the distinction between closing a tab and deleting a sequence, given the destructiveHint=true annotation.

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 description adds no parameter information, but schema description coverage is 100% — the schema already documents that sequence_id accepts a name or ID and defaults to the active sequence. Per the baseline for high coverage, a 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 uses a specific verb+resource pair — 'Close a sequence tab in the timeline' — which precisely distinguishes it from sibling tools like delete_sequence (removes the sequence), close_project, and close_source_monitor. The mention of 'tab' signals a UI-level operation, not data deletion.

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 guidance on when to use this tool versus its many siblings. Notably, it does not clarify when to use close_sequence instead of delete_sequence, close_project, or close_source_monitor, nor does it address the destructiveHint=true annotation by explaining the consequences of closing a sequence tab.

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 destructiveHint=true, and the description adds little beyond that. It does not disclose whether unsaved changes are discarded, whether closing is a no-op when no clip is open, or whether the Source Monitor panel itself remains active. No contradiction exists, but behavior beyond the annotation is not described.

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 clear sentence with no wasted words. The action, target, and location are front-loaded and immediately understandable.

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

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

For a zero-parameter tool with an output schema and a destructive hint, the description covers the core behavior adequately. The only small gap is the lack of clarity around edge cases, such as attempts to close when no clip is open, and the relationship to close_all_source_clips.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema description coverage is 100%, so the schema contains all needed information. The description adds nothing about parameters, but none are needed, making the baseline 4 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?

States a specific verb and resource: 'Close the clip currently open in the Source Monitor.' The singular 'clip currently open' differentiates it from the sibling close_all_source_clips, so an agent can identify the operation without opening any schema.

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

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

The description provides no explicit when-to-use guidance or comparison to alternatives such as close_all_source_clips. The singular scope is implied, but an agent is not told how to choose between closing one clip versus all source clips, nor what happens when no clip is open.

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