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

With no annotations, the description carries the full load and does add real behavioral context: the result is a genuine Premiere caption track that is editable/stylable in the Text panel, SRT-exportable, and burnable, plus RTL support. It omits what happens if a caption track already exists, whether the operation is additive or replacing, and failure modes.

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

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

Four short sentences, front-loaded with the core action, and the capability notes are placed after. Slightly list-like at the end but every sentence carries 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?

No annotations and no output schema, so the description must cover both safety profile and result; it covers the result qualitatively but leaves preconditions (active sequence, existing caption tracks) and the format enum semantics undocumented.

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

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

Schema coverage is only 33% and the description does not compensate: the format enum values (cea608, teletext, op42, etc.) are never explained, and the 'timed text' phrasing only loosely reinforces that start/end are times. The name and captions array are documented in the schema, so baseline-ish credit is fair.

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 — 'Create a caption (subtitle) track on the active sequence from timed text' — and qualifies the source of the data. It only implicitly differentiates from siblings like import_captions and add_text_captions by the 'from timed text' phrase rather than naming them.

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 'from timed text' hints that this is for programmatically supplied caption data rather than an imported file, but the description never says when to pick this over import_captions or add_text_captions, nor that an active sequence must exist first.

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

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

No annotations, so the description carries the full burden. It says where the marker lands (source media) but omits the important consequences: that a source-media marker may appear on every clip referencing that media, what happens when time falls outside the clip, and whether anything is returned or fails silently.

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, front-loaded with the verb and the key scope distinction, with zero filler. It is tight but arguably under-packed for a 7-parameter mutation 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?

A mutation tool with 7 parameters, no annotations, and no output schema is described in a single sentence. An agent still lacks the source-vs-timeline marker distinction spelled out, error behavior, and any note on the optional metadata fields.

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 57%; the description reinforces the time parameter with the 'inside the clip' constraint, which is real added meaning beyond 'Sequence time, seconds'. It says nothing about name, color, or comment, which are undocumented in both places.

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?

Specific verb (add) plus a precise resource: a marker on a clip's *source media* at a sequence time inside the clip. The 'source media' phrasing implicitly separates it from add_marker, add_markers, and add_project_item_marker, though it never names those siblings.

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

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

The phrase 'at a sequence time inside the clip' implies a precondition (the time must fall within the clip's bounds), but there is no explicit when-to-use guidance and no routing to add_marker / add_project_item_marker when a timeline- or project-level marker is wanted.

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

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

With no annotations, the description carries the full burden for a mutation tool. "Add/update" weakly implies an existing keyframe at the same time is overwritten, but it never confirms overwrite vs duplicate behavior, says nothing about required effect/property state, undo, or whether prior keyframes on that property are preserved. The "must be inside the clip" constraint is the one real behavioral fact offered.

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, no filler, and the operation is front-loaded before the time constraint. Nothing in it is wasted, even if more could usefully have been added.

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

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

For an 8-parameter, 7-required mutation tool with no annotations and no output schema, the description is thin. It omits what is returned, the default/explicit interpolation behavior, how effect/property resolution works, and what happens to conflicting keyframes, leaving the agent to infer invocation details from the schema alone.

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 75%, so most parameters are already documented, but the description adds genuinely non-derivable semantics for `time`: it is sequence time in seconds, not clip-relative time, and must fall inside the clip bounds. That resolves an ambiguity the schema ("number, minimum 0") leaves open.

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 concrete verb+resource ("Add/update a keyframe"), which is better than a tautology, but never says what the keyframe is attached to (an effect property on a clip) or how it differs from siblings like set_effect_property, get_keyframes, or set_keyframe_interpolation. An agent can guess the domain but not the exact operation boundary.

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 at all: nothing about how this relates to set_effect_property (static value) or when to use get_keyframes first to resolve names/indices. The only guidance given is a constraint on the time value, not on tool selection.

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

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

No annotations are provided, so the description carries the full behavioral burden. It only states that a marker is added to the active sequence, without explaining prerequisites, mutation side effects, duplicate-marker behavior, or what happens with different marker types or durations.

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, so it is concise. Its brevity is appropriate structurally, though the missing detail is better scored under contextual completeness.

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

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

For a 7-parameter mutation tool with no annotations and no output schema, the description is far too sparse. It should at least clarify sequence-level marker semantics, key parameters, and how this differs from the other marker-creation tools.

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

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

Schema description coverage is only 43%, so the description should compensate for undocumented parameters, but it adds no parameter meaning at all. The schema partially documents time, duration, and url, but name, comment, type, and color are left without descriptive guidance.

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: add a marker, scoped to the active sequence. This scope helps distinguish it from seq-level siblings like add_clip_marker and add_project_item_marker, though it does not explicitly name those alternatives.

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 'active sequence' implies when this tool applies, but the description gives no explicit when-to-use or when-not-to-use guidance. It also does not mention alternatives such as add_clip_marker, add_project_item_marker, or add_markers.

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

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

No annotations are provided, so the description carries the full behavioral burden. It signals a mutating bulk-add operation, but does not disclose atomicity, required active sequence state, validation behavior, duplicate handling, or any side effects beyond adding markers.

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 wasted words. It is perhaps overly terse given the nested parameter structure, but it is structurally clean.

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 mutating tool with no annotations, no output schema, and a nested markers array with zero schema descriptions, the definition is incomplete. An agent lacks enough context about marker object semantics and invocation prerequisites to use it reliably without inspecting the schema manually.

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 0% and the only parameter is a nested array of marker objects. The description does not explain the required 'time' field, optional fields like name/type/color/comment/duration, or the allowed marker types and color enums, so it barely compensates for the undocumented 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: adding multiple sequence markers at once. It distinguishes itself from singular add_marker and from clip/project-item marker tools by saying 'sequence markers' and 'many ... at once'. It does not explicitly name alternatives, so it is clear but not maximally 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 phrase 'many ... at once' implies bulk usage versus repeated calls to add_marker, and the examples 'chapters or beat markers' hint at use cases. However, there is no explicit when-to-use/when-not guidance, no mention of required active sequence context, and no named alternatives.

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

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

No annotations are provided, so the description carries the full behavioral burden. It indicates a mutation to a project item's media but does not explain permissions, side effects, duplicate handling, whether the project must be open, or what is returned.

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

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

The description is a single front-loaded sentence with no filler. It is terse, but the terseness reflects missing detail rather than wasteful wording.

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

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

For a six-parameter mutation with no annotations and no output schema, this is far too sparse. It conveys the core action and timing basis but leaves most parameter meanings, required nodeId semantics, return behavior, and project-state assumptions unexplained.

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

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

Schema description coverage is only 17%, and the description merely repeats the one documented parameter, 'source time.' The required nodeId and the name, color, comment, and duration parameters are left without semantic explanation.

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, 'add a marker,' plus the target scope: a project item's media at source time. This distinguishes it from timeline or clip marker siblings by naming the project-item media context, though it does not explicitly name those alternatives.

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 'project item's media (source time)' phrasing implies the appropriate context, especially versus clip or timeline markers. However, it never explicitly says when to choose this over add_marker, add_clip_marker, or add_markers, and it gives no prerequisites.

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

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

With no annotations the description carries the full burden, and it discloses meaningful traits: it renders via the system text engine with RTL support, auto-places on a free track above V1 unless trackIndex is set, and — importantly — the text clip is not editable afterward. It omits error behavior when no free track exists and what the call returns.

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

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

Three tight clauses with the verb and resource front-loaded; the engine note, placement rule, and edit limitation each add distinct information with no filler.

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

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

For a 17-parameter mutation tool with no annotations and no output schema, the description covers purpose, placement, and immutability well, but says nothing about the return value (e.g., created clip handle) or failure modes such as no available track.

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 82%, so baseline is 3, but the description adds real semantics for trackIndex (default is a free video track above V1) which the schema leaves entirely undocumented, and frames the font parameter as 'any installed font' with RTL support.

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: 'Add a text title to the timeline', plus the rendering engine used (system text engine, installed fonts, RTL). It does not explicitly contrast with close siblings like add_text_captions or add_captions, so sibling differentiation is left to the agent.

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?

Placement guidance ('on a free video track above V1 unless trackIndex is given') implies how it is used, and the note that edits require remove-and-re-add clarifies a workflow constraint. But there is no explicit when-to-use-this-vs-alternatives guidance relative to the caption/graphics tools.

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

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

With no annotations, the description carries the full burden, and it delivers the key non-obvious behavior: cues are rasterized into graphics clips on the timeline rather than editable caption objects. It leaves out mutation side-effects (e.g., where clips land, whether existing captions are replaced) and permission/prerequisite notes, which keeps it below a 5.

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

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

Two sentences, zero filler, with the core purpose front-loaded and the sibling disambiguation after it. Nothing repeated from the schema or the tool name.

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 15-parameter, no-annotation, no-output-schema tool, the description covers what it produces and when to prefer an alternative, but says nothing about the required captions array shape, whether styling is global across cues, or what the call returns. Adequate to pick the tool, thin on invocation detail beyond the schema.

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 ~80%, with descriptions on most styling params (font, color, shadow, fontSize, maxWidth, position, trackIndex defaults), so the schema already does the heavy lifting. The description adds no parameter-level meaning such as whether styling applies to all cues or how x/y interact with position beyond what the schema 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 and resource ('Burned-in styled captions as graphics clips') and clarifies the output form ('each cue becomes a text image on the timeline'), which distinguishes it from add_captions and add_text in the sibling list without the agent needing to open either 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?

Explicitly names the alternative (add_captions) and the condition that selects it ('when you want editable Premiere captions'), giving a clear this-vs-that routing rule. The 'burned-in / TikTok-Reels style' framing also implicitly scopes it to stylized social captions.

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

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

No annotations are provided, so the description carries the full behavioral burden and largely drops it. It does not say whether the sequence is modified in place, whether changes are undoable, what the defaults are when no counts are passed, or whether insertion shifts existing clips. Only the "active sequence" targeting is disclosed.

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

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

A single front-loaded sentence with no filler; the action and target are stated immediately. It is arguably too terse for a mutation tool, but nothing in it is wasted.

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 unannotated mutation tool with no output schema and two undocumented parameters, the description leaves key questions open: default track counts, placement semantics of top/bottom, and the effect on existing tracks. What is present is accurate but insufficient.

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

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

Schema description coverage is only 33% (only audioType has "Default stereo"), so the description needed to compensate and does not. It never explains that videoTracks and audioTracks are counts of tracks to create, nor what the default behavior is with zero required parameters.

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

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

States a specific verb and resource ("Add video and/or audio tracks") scoped to "the active sequence", which distinguishes it from remove_track, remove_empty_tracks and rename_track. The "top/bottom" phrasing is ambiguous since no parameter controls placement, but the core action is unmistakable.

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 "the active sequence" implies the prerequisite that a sequence must already be active, which is useful context. However, it never states when to use this versus create_sequence, create_sequence_from_clips or get_track_info, nor does it address what happens when videoTracks/audioTracks are omitted (0 required params).

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a timeline mutation but does not state side effects, permissions, whether existing clips are affected, or what the operation returns.

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

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

The description is a single front-loaded sentence with no wasted words. It states the core action and placement rule immediately.

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

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

The schema is rich and fully documented, and the purpose is clear. However, with no annotations and no output schema, the description should say more about mutation behavior and results for this timeline-editing 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%, and the schema fully documents nodeId, sourceIn, sourceOut, trackType, and trackIndex. The description adds no parameter meaning beyond the schema, so 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?

States a specific verb and placement behavior: placing media immediately after the last clip on a track. It is clear enough to distinguish append-at-end behavior, but it does not explicitly contrast itself with sibling tools such as insert_clip or overwrite_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 phrase "right after the last clip on a track" implies the append-at-end use case, but there is no explicit guidance on when to choose this over insert_clip, overwrite_clip, or move_clip. It also gives no exclusions or prerequisites.

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 zero annotations, the description carries the full disclosure burden and does not meet it: it never says whether the effect is appended or replaces an existing one, whether the operation is undoable, what permissions or active-sequence state are required, or what happens if the effect name is ambiguous. For a mutation tool with no annotation coverage, this is a substantial 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?

A single compact sentence with the core action front-loaded and the video/audio distinction placed in a clarifying parenthetical. No wasted words, though the brevity comes partly at the cost of the missing behavioral 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?

This is a 4-required-parameter mutation tool with no annotations and no output schema, so the description should establish prerequisites (active sequence, existing clip, effect must come from get_effects_list) and describe the result. None of that is present, leaving an agent to infer everything from the schema alone.

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 already explains trackType enum, 0-based indices, and that effectName comes from get_effects_list. The description adds no semantics beyond that, so the baseline of 3 for fully-covered schemas 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?

Clear verb+resource: adding an effect to a clip, with the useful elaboration that video effects apply to video clips and audio effects to audio clips. It is distinguishable from siblings like remove_effect and get_clip_effects, though it never explicitly contrasts with apply_transition, which is the nearest ambiguous neighbor.

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 statement of when to use this versus apply_transition, set_effect_property, or add_keyframe, nor any prerequisite such as needing an active sequence or a validated effect name. The only implicit routing is the video/audio parenthetical, which the enum in trackType already conveys.

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

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

No annotations are provided, so the description carries the full burden. It does add real behavioral context—default Cross Dissolve/Constant Power, 1 s, centered, and the handles limitation on length—but says nothing about whether an existing transition is replaced, required project/sequence state, or failure behavior.

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

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

Two dense sentences with zero filler; the core action and the defaults/limitation are front-loaded in a single readable line.

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

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

For a 7-parameter mutation tool with no annotations and no output schema, the description covers defaults and the handle constraint but omits replacement behavior, preconditions (active sequence/track targeting), and any result indication.

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 baseline is 3; the description goes slightly beyond by tying duration to available handles and clarifying that the transition is centered on the cut by default. It does not restate the position/alignment semantics that the schema already documents.

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

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

States a specific verb and resource ('Add a transition') plus the placement scope (clip start, end, or both) and built-in defaults. This separates it from apply_effect/get_transitions/remove_transition implicitly, though no sibling is named.

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 placement options and defaults imply normal usage (adding an edit-point transition), but there is no explicit when-to-use/when-not guidance and no pointer to alternatives such as remove_transition for undoing or get_transitions for inspection.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether the file must exist on disk, what happens to a proxy already attached, whether the operation is reversible, or what the result looks like for this mutation.

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

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

A single short sentence with no filler, front-loaded with the verb and resource. It is efficient, though so terse that the reader gains nothing about mechanics.

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?

A mutation tool with no annotations, no output schema, and one of two parameters undocumented. The description should at minimum cover file-path expectations and the effect on an already-attached proxy; neither is present.

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

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

Schema coverage is only 50%: nodeId is documented as coming from get_project_items / find_project_items, but proxyPath has no description anywhere. The description adds no information about path format, supported file types, or whether relative/absolute paths are accepted, so it fails to compensate for the coverage gap.

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?

Specific verb (attach) plus resource (proxy file to a project item), and the word 'existing' subtly separates it from the sibling create_proxy. It does not explicitly name create_proxy or toggle_proxies, so the differentiation is inferred rather than stated.

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 explicit when-to-use guidance and no named alternative. The phrase 'existing proxy file' hints that create_proxy is the path when no proxy file exists, but the agent must infer this and is told nothing about prerequisites or when not to use it.

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

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

With no annotations, the description carries the full burden. 'Create a copy' usefully signals the source sequence is preserved (non-destructive), and '(Adobe Sensei)' hints at AI-driven processing that may be slow. But it does not say whether the new sequence becomes active/selected, what 'motionPreset' or 'useNestedSequences' change behaviorally, whether timing/tracking accuracy depends on analysis, or what happens on failure.

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 wasted words and the key scoping detail (active sequence, aspect ratio) stated first. It is arguably undersized for a five-parameter creation tool, which is the only reason it is not a 5.

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 five-parameter creation tool with 40% schema coverage, no annotations and no output schema, the description leaves too much unsaid: the meaning of motionPreset and useNestedSequences, whether the result is a new sequence the agent can then act on, and any prerequisite state for the active sequence.

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

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

Schema coverage is only 40%: numerator/denominator already carry 'e.g. 9 for 9:16' examples, so the description's 'another aspect ratio' adds nothing new. The three undocumented parameters (newName, motionPreset, useNestedSequences) receive no explanation in either the schema or the description, so the description fails to compensate for the coverage gap.

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 gives a specific verb and resource ('Create an auto-reframed copy of the active sequence') plus the purpose ('for another aspect ratio'), which is more than a restatement of the name. It does not name a sibling such as clone_sequence or create_sequence_from_clips to disambiguate, but the auto-reframe capability is distinctive enough to tell apart.

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?

'of the active sequence' implies a precondition (the sequence must be active/open) and the aspect-ratio switch implies the intent, giving implied usage context. However, there is no explicit when-to-use vs. when-not-to-use guidance and no reference to alternatives like clone_sequence for a plain duplicate or set_sequence_settings for resizing an existing 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?

No annotations are provided, so the description carries the full burden. It does disclose the meaningful side effect (animation on the property is turned off), which is genuinely useful context, but it omits that the operation is bulk and irreversible (no undo guidance, no partial-failure behavior) for a destructive mutation.

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

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

A single short sentence, front-loaded with the action and resource, with the outcome in parentheses. Nothing wasted and nothing buried.

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 five-required-parameter destructive mutation with no annotations and no output schema, the description is thin: it never says keyframes cannot be restored, whether other properties are affected, or how to verify the result (e.g. via get_keyframes). The schema compensates for parameter detail but not for behavioral risk.

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 parameter documented including lookup hints (get_clip_effects, get_timeline_clips) and a trackType enum. The description adds nothing about the five required parameters, so 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?

States a specific verb ('Remove') and resource ('all keyframes from a property') and adds the consequence '(turns animation off)'. The word 'all' implicitly contrasts with the single-keyframe sibling remove_keyframe, though that sibling is never named.

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

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

Usage is only implied through 'all' — an agent can infer this is the bulk alternative to remove_keyframe, but the description never states when to pick this over remove_keyframe or get_keyframes, nor what prerequisites apply.

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

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

No annotations exist, so the description carries the full burden; it does disclose the extent of destruction ('all' markers) and the target ('active sequence'), which is exactly the key behavioral fact. However it says nothing about irreversibility, whether undo/redo can restore the markers, or behavior when no sequence is active — gaps that matter for an unannotated destructive tool.

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

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

A single front-loaded sentence with no filler; the verb and scope arrive in order and every word earns its place.

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

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

For a zero-parameter, no-output-schema tool, the definition covers what is deleted and where, which is enough to invoke it correctly. The only shortfall is the absence of failure-mode or recoverability context (no active sequence, undo availability).

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 has zero parameters, so there is nothing to document; the description correctly implies no targeting input is needed. Baseline 4 applies for a parameterless tool.

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

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

States a specific verb ('Delete'), resource ('markers'), and scope ('all... on the active sequence'), which cleanly distinguishes it from the singular remove_marker and from get_markers/update_marker in the sibling list. It stops short of naming a sibling explicitly, but an agent can tell what it does 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?

Usage is only implied: the word 'all' signals a bulk clear versus remove_marker for a single marker, and 'active sequence' signals the target. It never states when not to use it, that it is a bulk destructive alternative to remove_marker, or any prerequisite such as an open/active sequence, leaving the agent to infer.

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

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

No annotations are provided, so the description carries the full burden. It does not say whether the operation is destructive, whether it is reversible (undoable), what happens if no in/out points are set, or what the response looks like. For a mutation tool with zero annotation coverage this is a meaningful gap.

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

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

A single front-loaded sentence with no filler. It is tight, though the brevity is also the source of the missing behavioral 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?

Enough for a one-parameter tool whose schema is fully documented and which returns nothing structured, but with no annotations and no output schema the description should at least state whether the clear is undoable and what happens on items without in/out points.

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

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

Schema coverage is 100% and the nodeId parameter already documents its source (get_project_items / find_project_items). The description adds nothing beyond the schema, 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?

States a specific verb (Clear) and a specific resource (source in/out points on a project item), which is enough to distinguish it from set_project_item_in_out. It stops short of naming that sibling or clarifying the overlap with clear_sequence_in_out, which sits right next to it in the tool 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?

There is no guidance on when to use this versus set_project_item_in_out, clear_sequence_in_out, or trim_clip. The agent must infer that 'clear' is the inverse of 'set' and that this operates on project items rather than sequences.

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

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

No annotations are provided, so the description carries the full burden. It doesn't say whether this acts on the active sequence, whether the previous in/out values are discarded, or whether it's an undoable edit – all relevant for a mutation of sequence state.

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?

Seven words, front-loaded with the action and target; nothing superfluous. It is terse to the point of thinness, but that is a completeness issue rather than a structural one.

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-arg state mutation with no annotations and no output schema, the description should at least identify the affected object (the active sequence) and the effect on current in/out points. Neither is stated.

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?

Zero parameters, so the schema is complete by definition; baseline is 4. Nothing about parameters is needed or missing.

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?

Specific verb ("Reset") plus the affected resource ("in/out") and scope ("whole sequence"), which separates it from set_sequence_in_out on the same target. Slightly undercuts itself because "in/out" is ambiguous across sequence, clip and project-item contexts, and siblings like clear_project_item_in_out exist.

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 indication of when to use this versus set_sequence_in_out (which sets points) or clear_project_item_in_out. The agent must infer the clearing semantics entirely from the word "Reset".

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing beyond the fact that a copy is made. It does not say where the duplicate lands (project panel, bin, active sequence), whether the clone becomes the active sequence, or what happens to the name if newName is omitted.

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 single three-word phrase is front-loaded and wastes nothing, which is good structure. But its brevity comes at the cost of under-specification rather than genuine economy.

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

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

For a mutation tool with no annotations, no output schema, and one of two parameters undocumented, the description should explain side effects and return behavior but does neither. The clone does not appear in the general resources after the call, so the description is insufficient for confident invocation.

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

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

Schema coverage is only 50%: the 'sequence' parameter is annotated with a default of active, but 'newName' has no schema description and the description adds nothing about naming behavior, defaults, or whether a copy is auto-named when it is omitted. With zero required parameters the agent gets no guidance on the minimal valid call.

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?

"Duplicate a sequence" states a specific verb (duplicate) and resource (sequence), so the agent knows the core action without opening the schema. However, with siblings like create_sequence, create_subsequence, and duplicate_clip in the toolset, the description does no work to distinguish a sequence clone from those alternatives.

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 context is given at all: nothing says whether to clone instead of using create_sequence, creating a subsequence, or duplicating individual clips. The agent must infer the selection criteria entirely from the terse name.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the sliding-left effect but does not explain scope (selected clips vs. entire track), default track behavior, whether the operation is undoable, or how it interacts with sync/linked clips.

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 filler. Every word contributes to the stated effect.

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 editing tool with no output schema, the description covers the core effect. However, it omits how trackType and trackIndex affect scope and what the default behavior is, which matters 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 only 50%: trackIndex is documented, but trackType and its enum are undocumented. The description adds no parameter meaning at all, leaving trackType semantics to inference.

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 gives a specific verb and effect: removing empty space between clips by sliding them left. It clearly identifies the operation, though it does not distinguish it from adjacent editing siblings such as ripple_delete_range or move_clip.

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

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

It implies the operation is for closing timeline gaps but gives no explicit guidance on when to use it versus alternatives, no prerequisites, and no exclusions. An agent must infer the appropriate context.

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

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

No annotations are provided, so the description carries the full burden. It does not say whether closing is reversible, what happens to unsaved changes if save is false, whether the project is unloaded from memory, or what happens on failure — all critical for a destructive-feeling operation.

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

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

A single short sentence with zero filler and the key scope word ('active') front-loaded. Brevity is appropriate, though it tips into under-specification rather than tightness.

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 project-level mutation with no annotations and no output schema, the description omits prerequisites (is a project open?), side effects on open sequences, and post-close state. An agent could call it correctly only by guessing.

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?

Only one parameter and schema coverage is 100%, with the schema itself explaining the default (true) for 'save'. The description adds nothing beyond the schema, but the baseline applies when the schema does the work.

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 concrete verb and resource ('Close the active project'), and the 'active' qualifier scopes the target. It implicitly distinguishes from close_sequence and open_project, though it never names them.

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 on when to close the project versus saving it first, versus save_project or close_sequence, nor on what a caller should do if a sequence is still open. The agent must infer all invocation 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?

With no annotations provided, the description carries the full burden. It implies a non-destructive UI action by saying 'tab', but never states whether unsaved changes are lost, whether the sequence stays in the project, or what the tool returns — all critical for a close operation.

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

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

A single front-loaded phrase with no wasted words. It is terse to the point of thinness, but nothing in it is padding.

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

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

One optional parameter, no annotations, no output schema — a very simple surface — yet the description says nothing about the outcome of closing a tab or its preconditions. An agent cannot predict whether this discards state, so the definition is not complete for the operation it performs.

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% (the 'sequence' param documents its default of 'active'), so the schema already does the work. The description adds no meaning about accepted values or what happens when the parameter is omitted, 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?

States a specific verb and resource — 'Close a sequence's timeline tab' — and the addition of 'timeline tab' meaningfully distinguishes it from delete_sequence, which appears in the sibling list. It stops short of a full 5 because 'close a sequence' alone could be read as destroying the sequence, and no sibling is named explicitly.

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 indication of when an agent should close a timeline tab rather than leave it open, and no mention of delete_sequence as the alternative for actually removing a sequence. The agent must infer the use case entirely from the name.

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

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

With no annotations, the description carries the full burden for what is effectively a destructive consolidation. It does not say whether duplicate source files are deleted from disk or only merged in the project, whether timeline clips referencing duplicates get relinked, or whether the operation is reversible.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity reflects missing behavioral detail rather than tight editing of a complete 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?

A project-wide destructive merge with no annotations, no output schema, and no parameters should explain scope, irreversibility, and expected result. The one-line description leaves the agent guessing at all three before committing to an irreversible operation.

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

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

The tool takes zero parameters, so there is nothing for the schema to document and the baseline is 4. The phrase 'in the project' is the only scoping information available, confirming the operation applies project-wide.

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 (merge) and a specific resource (duplicate media items in the project), and no sibling tool covers de-duplication, so an agent can distinguish it from relink_media or delete_project_items. It stops short of defining what counts as a duplicate (same filename, hash, media path), which leaves the scope slightly fuzzy.

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 on when to invoke this versus manually removing duplicates with delete_project_items, nor any precondition such as running it before export or after import_media. The agent must infer the workflow entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: it does not say what happens if a bin with the same name already exists, whether the bin is created at the project root by default, whether the operation is reversible/undoable, or whether the new bin is returned. For a mutation tool with zero annotation coverage this is a significant 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?

A single short sentence with the resource front-loaded and zero filler. It is efficient, but the terseness is partly what leaves the behavioral gaps rather than being disciplined minimalism.

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

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

For a simple two-parameter mutation with no annotations and no output schema, the description should at minimum say which project is targeted and what is returned or what duplicate-name handling looks like. As written, an agent can call it but cannot predict its effects or result.

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

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

Schema coverage is 50%: parentBinPath is well documented in the schema (path format and '' = project root), while `name` is undocumented. The description adds no parameter detail beyond the schema, so the documented half does the work and the bare `name` string must be guessed at (uniqueness, allowed characters). Baseline 3 fits a mid-coverage 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?

States a specific verb and resource ("Create a bin") and disambiguates the term with "(folder)" plus the location "in the project panel". No other sibling creates bins, so the tool is easy to distinguish, though it does not distinguish itself from project-item creation in general (e.g., create_sequence).

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 on when to use this versus alternatives such as import_media or create_sequence, nor any prerequisites (e.g., a project must be open). The agent must infer usage entirely from the name and one clause.

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

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

With no annotations, the description carries the full burden; it does usefully signal asynchrony via 'Queue' (the job goes to Media Encoder rather than completing inline). It omits what happens to an existing proxy, whether Media Encoder must be running, and how to follow up on the queued job (get_status).

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 compact sentence with the key noun (proxy creation) and the required input type front-loaded. It is efficient but underspecified rather than dense — a second sentence on follow-up or overwrite behavior would earn its place.

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

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

For a job-submitting operation with no annotations and no output schema, the definition leaves out the outcome: what the returned queued state means, whether an existing proxy is replaced, and how completion is observed. Everything needed to identify the call is present, but not everything needed to use it safely.

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 parameters are already documented with their sources. The description only reinforces that presetPath should be an ingest/proxy .epr, adding no format or validation detail 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?

States a specific verb ('queue proxy creation') and resource ('project item ... in Media Encoder'), plus the exact artifact needed ('ingest/proxy preset (.epr)'). It is reasonably distinguishable from attach_proxy/toggle_proxies by its focus on generating a proxy rather than attaching or switching existing ones, though that contrast is never made explicit.

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 intent (create proxies for a project item) is implied and the preset prerequisite appears via the schema reference to get_export_presets with filter 'proxy'. There is no explicit when-to-use vs attach_proxy, no note about AME needing to be running, and no statement about what to do when a proxy already exists.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses that the sequence is created and opened, and it provides default dimensions/fps, but it omits prerequisites such as whether a project must be open, name uniqueness/conflict behavior, what 'open' changes in application state, and how presetPath interacts with defaults.

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

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

The description is two short sentences, front-loaded with the core action and followed by useful format defaults. Every sentence contributes information without filler.

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

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

For a mutation/creation tool with no annotations, no output schema, and low schema coverage, the description provides useful default-format context but leaves important gaps: required project state, where the sequence is created, naming constraints, error behavior, and presetPath interaction.

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

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

Schema description coverage is only 40%, with fps and presetPath documented in the schema but name, width, and height undocumented. The description usefully explains the default 1920x1080 25 fps and gives a vertical-format example, partially compensating for the low coverage. It still does not explain the required name parameter or the interaction between presetPath and the default width/height/fps.

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: 'Create a sequence and open it.' It also adds default format details, making the operation concrete. However, it does not distinguish this from sibling creation tools such as create_sequence_from_clips, clone_sequence, or import_sequences.

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

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

Usage is only implied: the tool creates a new blank sequence with default settings, and width/height/fps can be set for alternate formats. There is no explicit guidance on when to use this versus create_sequence_from_clips, clone_sequence, or import_sequences.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the sequence matches the clips' settings and preserves the given order, but it does not explain required project context, mutation effects, default naming, bin behavior, or failure conditions.

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 unnecessary wording. It efficiently conveys the core action, source material, and ordering 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?

For a mutation tool with no annotations and no output schema, the description is under-specified. It does not cover project prerequisites, naming behavior, bin placement, side effects, or what an agent should expect after creation.

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 67%, with nodeIds and binPath already described in the schema. The description reinforces that clips are placed in order and that their settings are used, but it adds little for the undocumented name parameter and does not clarify default naming or binPath semantics.

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: "Create a sequence" from clips, with clips placed in order. It implicitly distinguishes itself from a plain sequence-creation tool by saying the sequence matches the clips' settings, but it does not explicitly name the 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 gives no explicit guidance on when to use this tool versus siblings such as create_sequence, clone_sequence, or import_sequences. The usage is inferable from "from clips," but no conditions, prerequisites, or alternatives are 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?

No annotations are provided, so the description carries the full behavioral burden. It says a subclip is created but does not disclose whether the original item is modified, whether the operation is reversible/undoable, what permissions or active project state are required, or where the new subclip appears. For a mutation tool, this is a significant 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?

A single short sentence with no filler. It is efficient and front-loaded, though the terseness comes at the cost of substance captured elsewhere.

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

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

For a 5-parameter creation tool with no annotations and no output schema, the description is too thin. It does not explain prerequisites (e.g., an open project), the relationship between in/out points and hardBoundaries, or what the caller gets back, so an agent lacks enough context to invoke it confidently.

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

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

Schema description coverage is 80%, so the schema already documents nodeId provenance (from get_project_items / find_project_items), inPoint/outPoint in seconds, and hardBoundaries. The description adds no parameter-level meaning beyond the vague phrase 'part of a project item', 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?

States a specific verb (Create) and resource (subclip) and names the source (part of a project item). It is clear what it does, but it does not distinguish itself from related siblings such as create_subsequence or duplicate_clip, leaving the agent to infer when this exact tool is appropriate.

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 explicit when-to-use guidance, no exclusions, and no mention of alternatives like create_subsequence or razor_clip. The name implies a scenario, but the description offers no routing information beyond the one-line purpose.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says a new sequence is created from the in/out range; it does not explain whether the new sequence becomes active, how track targeting is affected, what happens when no in/out range exists, or any permissions or 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 wasted words. It immediately identifies the operation and its source range.

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

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

For a mutation tool with no annotations and no output schema, the description is too sparse. It omits important behavioral context such as the active-sequence prerequisite, what the resulting sequence contains, and how the optional track-targeting parameter changes the outcome.

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 that ignoreTrackTargeting includes all tracks rather than only targeted ones. The description itself adds no parameter-specific meaning, 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?

States a specific action and source object: create a new sequence from the active sequence's in/out range. This distinguishes it somewhat from siblings like create_sequence and create_sequence_from_clips, though it does not name alternatives explicitly.

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 use case by naming the active sequence's in/out range as the source, but it does not explain when to choose this over create_sequence, create_sequence_from_clips, or clone_sequence, nor does it state exclusions or prerequisites beyond the active sequence context.

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

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

With no annotations, the description carries the full behavioral burden and does disclose one important side effect: clips referencing deleted items are removed from timelines. It stops short of saying the operation is irreversible, whether undo applies, or what happens to media on disk versus project references.

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 front-loaded sentence with the resource and the destructive side effect packed into a parenthetical; no filler.

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

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

For a destructive tool with no annotations, no output schema, and an undocumented parameter, the description is too thin. The cascade warning is useful, but irreversibility, ID provenance, and distinction from delete_sequence are missing.

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

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

Schema description coverage is 0% for the single required parameter nodeIds, and the description never mentions it. It does not clarify that multiple IDs are accepted, what kind of identifier a 'node id' is, or where to obtain one.

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?

A specific verb (delete) and resource (project items, sequences, bins) with the affected entity types spelled out. It does not, however, distinguish itself from the sibling delete_sequence, which appears to overlap with the 'sequences' case mentioned here, so an agent gets no routing rule.

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 on when to use this versus delete_sequence or the narrower deletion tools, and no stated preconditions (project open, item not in use, etc.). The parenthetical describes a consequence, not a usage condition.

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

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

No annotations are provided, so the description carries the full disclosure burden for a destructive operation. It does not say whether deletion is permanent, whether it can be undone, whether the sequence must be closed or active first, or whether underlying media is affected; 'from the project' is the only faint hint and is not elaborated.

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 short, front-loaded sentence with no waste. It is lean to the point of under-specification rather than being padded.

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

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

For a destructive, annotation-free tool, the description leaves out irreversibility, preconditions, and side effects on media and open sequences. Given no output schema and no annotations, this is materially incomplete.

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?

With 100% schema description coverage, the single 'sequence' parameter is already documented as 'Sequence name or ID (from get_sequences)'. The description adds nothing on accepted formats or ambiguity between name and ID, 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?

Specific verb plus resource: 'Delete a sequence from the project'. An agent can tell this is a deletion of a whole sequence rather than of items or tracks, but the description never distinguishes it from close_sequence, which is the nearest ambiguous sibling.

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, no prerequisites, and no mention of the close_sequence alternative that an agent would plausibly confuse it with. The agent must infer the difference from the sibling names 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?

No annotations are supplied, so the description carries the full behavioral burden. It says the selection is cleared but does not disclose prerequisites such as whether an active sequence is required, what kind of timeline selection is affected, or what happens when nothing is selected.

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. For a zero-parameter operation, it is appropriately sized.

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

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

The tool is simple, has no output schema, and no annotations, so minimal description is needed. Still, the description leaves useful context unstated, including prerequisites and the exact scope of the selection being cleared.

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

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

The tool takes zero parameters, and the schema is empty with 100% description coverage. There are no parameter semantics for the description to clarify, so the baseline score of 4 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 and resource: clearing the timeline selection. It is much clearer than the bare tool name, but it never names the sibling it contrasts with, such as get_selection or select_clips, so the differentiation is implied rather than explicit.

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 explicit guidance about when to use this tool rather than get_selection, select_clips, or project-panel selection tools. The intended use is inferable from the name and sentence, but no alternatives or conditions are 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?

With no annotations, the description carries the full burden, and it does disclose the critical behavioral fact that the destination is overwritten (destructive) and that source in/out points are preserved. It is silent on whether the original clip remains in place (implicit in 'duplicate' but never stated) and on permissions or return value.

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 the action front-loaded and no filler; every clause carries information. The stacked parentheticals make it telegraphic, but nothing is redundant.

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

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

For a 5-parameter destructive mutation with no annotations and no output schema, the essentials are only partly covered: overwrite behavior is flagged, but whether the source clip persists, the source/target track relationship, and expected response are left unstated.

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 each parameter is documented in the schema, so the baseline of 3 applies. The description's phrase 'to a time and track' loosely maps to time plus targetTrackIndex, but it does not clarify the source-vs-destination track distinction (trackIndex vs targetTrackIndex) or that targetTrackIndex is optional.

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 ('Copy a clip'), plus the scope constraint '(same source range)' and the destination ('to a time and track'). An agent knows what the operation does, but the description never distinguishes it from the many adjacent siblings (overwrite_clip, insert_clip, move_clip, move_clip_to_track), which is exactly where confusion is likely.

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 statement of when to use this versus overwrite_clip, insert_clip, or move_clip_to_track, and no prerequisites. The only usage-adjacent signal is the parenthetical '(overwrite)', which hints at the resulting behavior rather than when to select 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?

With no annotations, the description still discloses the important side-effect chain: an external ElevenLabs call, a media import, and an optional timeline placement. It omits the prerequisites an agent would want – API key/voice availability, cost or rate limits, and whether the placement is destructive to existing track content.

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 that sequences the three effects in order of execution. Efficient, though the brevity costs it the parameter and prerequisite detail the tool 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 9-parameter, annotation-free tool with no output schema, the description covers the workflow shape but not the return value (project item? clip? newly imported file?) nor the tuning parameters. An agent can start the call but will be guessing about defaults and results.

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

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

Schema description coverage is only 44% (9 params, 4 described), so the description needs to compensate. Instead it says nothing about text, speed, style, stability, or similarityBoost – the agent gets no meaning beyond the field names, and the voiceId cross-reference to elevenlabs_list_voices lives only in 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?

States a specific verb chain (generate, import, optionally place) and the resource (voiceover, audio track), which is far more informative than a bare name restatement. It does not, however, distinguish itself from the sibling elevenlabs_voice_lines, which an agent could reasonably confuse with single-voiceover generation.

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 'optionally place it on an audio track' implicitly explains when to supply start/audioTrack versus importing only. There is no explicit guidance on when to choose this tool over elevenlabs_voice_lines (multi-line dialogue) or what prerequisite voices/API access are needed.

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

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

No annotations are provided, so the description carries the full burden, yet it says nothing about authentication requirements (ElevenLabs API key), whether the listing is paginated, or whether it includes default/shared/generated voices. Only the 'on your account' scoping hints at ownership behavior.

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

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

A single sentence with no waste, and the scope constraint is front-loaded. It is efficient but so terse that it borders on under-specification rather than optimal 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?

For a zero-parameter list tool with no annotations and no output schema, the description is minimally adequate: the agent can call it, but it does not know what a voice record contains or whether the result is truncated. One extra clause about the returned fields would make it 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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. It correctly implies the call is unfiltered and account-scoped.

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 (List) and resource (voices) scoped to the user's ElevenLabs account, so the agent knows exactly what it returns. It does not distinguish itself from the sibling ElevenLabs tools (elevenlabs_generate_speech, elevenlabs_voice_lines), which is the only gap.

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 explicit when-to-use guidance and no mention of the related sibling elevenlabs_voice_lines, which an agent could plausibly confuse with voice discovery. Usage is only inferable from the tool name and one-line purpose.

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

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

No annotations are provided, so the description carries the full burden. It implies a write operation that creates timeline clips, but says nothing about which track they land on (the audioTrack param default A2 is only in the schema), whether existing content is overwritten, what happens on partial failure, or that an ElevenLabs API key/voice must be configured.

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, front-loaded with the core action and behavior, with the example parenthetical earning its place as the only usage cue. Nothing redundant.

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

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

For a mutation tool that generates multiple audio assets and places them on a timeline, with no annotations, no output schema, and half the parameters undocumented, the description leaves the agent guessing about track targeting, overwrite behavior, and how to pick a voice. It is significantly under-specified for this complexity.

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

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

Schema coverage is only 38% across 8 parameters, and the description addresses just the line objects ('one clip per line', 'at its time'). The six voice-tuning parameters (speed, style, stability, similarityBoost, modelId, voiceId) and audioTrack are never explained in the description, and three of them have no schema description either.

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?

Names a specific verb and resource: generate one voiceover clip per line and place each at its time. That distinguishes it operationally from elevenlabs_generate_speech, though it never names that sibling explicitly, so the differentiation is inferred rather than stated.

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 parenthetical 'e.g. narration matching captions' gives one concrete usage scenario, which is genuine context. However, there is no explicit when-to-use versus when-not guidance and no pointer to elevenlabs_generate_speech for a single clip or to add_captions for the caption side of the workflow.

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

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

No annotations, so the description carries the burden and it does add real behavior: return semantics (last expression value, objects JSON-encoded), available globals (`app`, `qe`, helper functions), and DOM time units. It never warns that arbitrary script runs with full application privileges and can mutate or destroy the project, and says nothing about error propagation or execution limits.

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, purpose front-loaded, then return contract, then execution environment. No restatement of the tool name or filler.

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

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

With no output schema, the description correctly supplies the return-value contract, which is the main thing an agent would otherwise lack. For an arbitrary-code tool with zero annotation coverage, the remaining gap is safety and failure behavior (what happens on script error, whether `save_project` is needed afterwards).

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

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

Schema coverage is only 33%, so the description must compensate, and it does for the most important parameter: what the `script` body is evaluated as, what it returns, and which globals are in scope. `timeoutSeconds` is left undocumented in both schema and description, though its 1–3600 bounds make it largely self-explanatory.

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

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

Names a specific verb and resource ("Run raw ExtendScript in Premiere Pro") and immediately positions itself as the escape hatch for anything the specialized sibling tools cannot do. An agent can distinguish this from the ~140 narrow siblings without inspecting 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?

"for anything the other tools don't cover" is explicit routing guidance that sets the escape-hatch condition and implicitly tells the agent to prefer dedicated tools first. It lacks a concrete fallback example or a note that the dedicated tools are preferred for destructive/structural edits, so it isn't a full when/when-not pair.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about writing to disk, overwriting an existing file at outputPath, permissions, or what happens when no sequence is active. The only implicit trait is that it operates on whatever sequence is currently active.

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 filler, which is efficient. However, its brevity is under-specification rather than discipline, given what the schema demands.

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

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

For a 5-parameter export tool with no annotations and no output schema, the definition omits parameter meaning, side effects, and failure conditions. The format/purpose line is useful but far from sufficient to call this reliably.

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 0% across five parameters, and the description mentions none of them. Required outputPath, sampleRate, mixdownAudio, bitsPerSample, and explodeToMono are entirely unexplained, leaving the agent no guidance on which to set or what values mean.

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 (export the active sequence) plus the format (AAF) and target applications (Avid / Pro Tools), which meaningfully separates it from export_omf and export_fcp_xml. It stops short of a 5 only because it doesn't contrast itself explicitly with those siblings.

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

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

The target-app hint ('for Avid / Pro Tools') loosely implies when this format is appropriate, but there is no explicit statement about when to choose AAF over export_omf, export_fcp_xml, or export_sequence, and no prerequisite conditions (e.g., an active sequence must exist).

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the default codec/format (WAV 48 kHz 16-bit) and that an alternate audio preset is accepted, but says nothing about overwriting an existing file at outputPath, whether the export is blocking, or what happens on failure.

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 compact sentence with the scope constraint and default format front-loaded; nothing is wasted. It is short to the point of under-specification rather than bloated.

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

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

No output schema and no annotation coverage, so the description should cover the return value (file path? job id?) and the range semantics. It covers neither, leaving an agent able to guess the call shape but not the effect or result.

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 0%, so the description must compensate, yet it only gestures at 'preset' and omits outputPath entirely. The 'range' enum (entire/inOut) is never explained, leaving a required path and a scope selector ambiguous.

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 (Export) and resource (sequence audio) and emphasizes 'only', which distinguishes it from siblings like export_sequence, export_omf, and export_frame. It does not name any of those siblings explicitly, so differentiation relies on the agent inferring from the word 'only'.

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

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

Usage is implied ('only the sequence audio') rather than stated: there is no explicit 'use this when you want audio-only output, use export_sequence for full media' contrast against a crowded export sibling set. An agent can infer the condition but must do the routing work itself.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose side effects (writing a file to disk), overwrite behavior, permission requirements, or what happens if no active sequence exists. For an export tool with zero annotation coverage, this is a significant 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?

A single clear sentence that is front-loaded and free of waste. It is appropriately concise, though the terseness contributes to gaps in other dimensions.

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 no annotations, no output schema, and a required parameter that is undocumented in both schema and description, the definition is incomplete. An agent lacks necessary information about error handling, return value, and parameter usage to invoke this tool confidently.

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

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

There is one parameter (outputPath) with 0% schema description coverage, and the description never mentions it. The description implies writing to a path but adds no details about path format, directory requirements, or extension handling.

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 ('Export'), resource ('active sequence'), and output format ('Final Cut Pro XML'). This implicitly distinguishes it from sibling export tools like export_omf and export_aaf by format, but does not explicitly name or contrast with those alternatives.

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 no guidance on when to use this tool versus alternatives such as export_sequence, export_aaf, or export_omf. There is no mention of prerequisites (e.g., needing an active sequence) or exclusions.

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

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

With no annotations, the description does useful work: it discloses that effects are rendered, that the frame is displayed, and that a PNG is written as a side effect. It does not cover overwrite behavior for existing files, permission/error conditions, or what happens when returnImage is false.

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, purpose front-loaded, no filler. The second sentence about the PNG could arguably be merged, but it is informative rather than redundant.

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 four-optional-parameter tool with no output schema and no annotations, the description is adequate but thin on return behavior (what the image looks like when returnImage=false) and on failure modes. An agent could call it, but would be guessing at edge 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 description coverage is 100%, including defaults for time, maxWidth, outputPath, and returnImage, so the schema carries parameter meaning. The description only echoes the PNG-save behavior tied to outputPath and adds no format or unit detail 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?

States a specific verb+resource ('Render one frame of the active sequence') and adds the scope 'with all effects'. It is distinguishable from export_sequence/render_previews by being a single-frame preview, though it never names those siblings explicitly.

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 clause 'so you can check how the edit looks' implies the inspection use case, but there is no explicit when-to-use vs. when-not-to-use and no routing to alternatives like render_previews or export_sequence. The dependency on an active sequence is implied only 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 no annotations, the description carries the full behavioral burden, but it only says what is exported. It does not disclose overwrite behavior, permissions, active-sequence requirements, output file handling, or other operational constraints an agent would need for a safe export.

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 wasted wording. It is concise and appropriately structured, though its brevity reflects under-specification rather than efficient completeness.

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 export tool with four undocumented parameters, no annotations, and no output schema, the description is too thin. It states the general action but leaves critical invocation details—especially the required output path and export settings—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?

The schema has 0% description coverage, and the description does not mention any of the four parameters. It does not explain outputPath, sampleRate, handleFrames, or bitsPerSample, so the description provides no semantic guidance beyond the bare schema.

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

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

The description states a specific verb and resource: export the active sequence audio as OMF. The OMF format makes it more specific than a generic audio export, though it does not explicitly differentiate itself from sibling tools like export_aaf or export_audio.

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 the tool might be used—when OMF output is needed—but provides no explicit when-to-use guidance, prerequisites, or alternatives. It does not mention when to choose export_aaf, export_fcp_xml, or export_audio instead.

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

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

With no annotations, the description does carry some behavioral burden and does disclose the key trait: this is a blocking synchronous render that completes before returning, performed in Premiere rather than an external encoder. It omits other important behavior: whether an existing file at outputPath is overwritten, expected render duration/timeout risk for long sequences, and whether the project's active sequence or settings are mutated.

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, with the core action and the completion semantics front-loaded and the default preset follow-up where it belongs. Every sentence earns its place.

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

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

For a 4-parameter render tool with no annotations and no output schema, the definition covers the action and the default preset but leaves gaps an agent would care about: overwrite behavior at outputPath, how long it may block, and what is returned on success (path, job id, or nothing). Adequate, not complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a fact absent from the schema: the default preset is 'H.264 Match Source - High bitrate', which materially affects the rendered output. That is a genuine value-add even if the remaining parameters are fully documented in 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?

States a specific verb and resource ('Render the ... sequence to a file') plus a scope qualifier ('active (or named)'). It is clearly distinguishable from export_sequence_as_project, export_omf, export_frame and export_audio, though it never explicitly contrasts with the closest sibling, queue_export.

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 'wait until it is done' implies a use case (you need the file before continuing) which implicitly separates it from a queued/background export, but the description never names queue_export or states when to choose one over the other. No prerequisites or exclusions are given, so the agent must infer routing 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?

With no annotations, the description carries the full burden. It does usefully disclose that media is referenced rather than copied, but omits whether an existing file at the target path is overwritten, whether the current project is modified, and what happens if no sequence is active.

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 front-loaded sentence with zero filler, but at that length it leaves no room for the prerequisite and overwrite details an agent would need.

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

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

No output schema and no annotations, so the description must cover return value, side effects, and path constraints itself. It does not: nothing is said about what is returned, whether media is consolidated, or how failures (missing active sequence, invalid path) surface.

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 0% and the single outputPath parameter is never mentioned in the description. The implied .prproj extension is the only hint about the value; there is no guidance on absolute vs. relative paths, directory existence, or overwrite behavior.

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

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

States a specific verb (save/export) applied to a named resource (the active sequence) and a named output format (.prproj), which separates it from save_project, save_project_as, export_sequence, export_fcp_xml, and export_aaf. It does not explicitly name those siblings, so it falls short of a 5.

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 never says when to choose this over save_project_as (whole project) or export_sequence (media render), nor does it state prerequisites such as an active sequence being open. Usage is only inferred from the phrase 'as a separate .prproj'.

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

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

No annotations are provided, so the description carries the full burden. It implies a keyframe-adding write operation but does not state whether existing keyframes are replaced, what happens when fadeIn/fadeOut are omitted, or whether the change is undoable; for a mutation tool this is a significant 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?

A single front-loaded sentence with no filler. It is efficient, though its brevity leaves the behavioral gaps noted elsewhere rather than being a conciseness problem.

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?

Five parameters, no annotations, and no output schema: the description should disclose keyframe side effects, interaction with existing volume levels, and error conditions. It says nothing about these, leaving the agent guessing about consequences of the call.

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%, with units, 0-based indexing, and the volumeDb default ('current') already documented. The description adds only the notion that fades are independently optional ('and/or'), so the 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?

Uses a specific verb ('Fade') and resource ('an audio clip') with a qualifier ('with volume keyframes') that distinguishes it from plain volume-setting siblings like set_clip_volume. It does not explicitly name an alternative sibling, but the operation is identifiable without opening the schema.

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

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

No statement of when to use this over set_clip_volume, set_clip_channel_volume, add_keyframe, or apply_transition, and no prerequisites such as requiring an audio clip. The mention of 'and/or' only hints that each fade is optional; usage is left 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?

With no annotations, the description carries the full burden. It does not state that this is a read-only lookup, which sequence(s) are searched, whether matching is case-sensitive, or whether there is a result cap — all of which an agent needs before relying on the results.

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 short, front-loaded sentence with no filler; the resource and filter appear immediately. It could have carried one more clause of guidance at essentially no cost, but nothing present is wasted.

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 search tool with no annotations, no output schema, and an undocumented parameter, the description is thin: search scope (active sequence vs. all sequences) and the shape of the returned clips are left entirely unknown. The output schema's absence means the description should have said more about results.

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 0% for the single 'query' parameter, but the description does compensate by defining the match semantics: the string is matched as a substring of the clip name. It still doesn't clarify case sensitivity or escaping, so the gap is only partially closed.

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 (find) plus resource (timeline clips) and the match criterion (name contains text), which is more informative than a bare 'get'. It does not explicitly distinguish itself from siblings like get_timeline_clips or find_project_items, so the agent must infer scope from the word '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 phrase 'whose name contains text' hints that this is a partial-name search, but the description never says when to prefer it over get_timeline_clips, get_clips_at_time, or find_project_items, nor what happens on no match. No exclusions or alternatives 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?

With no annotations, the description carries the full burden, but it does disclose useful behavior: matching is case-insensitive substring rather than exact, and the search spans all bins with no scoping. It does not state that this is a read-only operation, what the results contain (IDs, item types, ordering), or whether results are capped.

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 tightly written sentence with the matching rule and scope front-loaded and no filler. It is arguably too terse for a search tool, but nothing in it is wasted.

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 search with no annotations and no output schema, the description should say what comes back and whether results are ordered or limited. It covers the matching semantics and scope well, but leaves return shape and the type filter 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 coverage is 50%; the undocumented query parameter is compensated for by the description's explanation of case-insensitive substring matching. However, the type filter (with its all/clip/file/bin/sequence enum) is never mentioned in the description, so half the parameter surface is left entirely to the schema.

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

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

States a specific verb (search), resource (project items), matching semantics (case-insensitive substring), and scope (across all bins), so an agent knows exactly what it retrieves. It does not explicitly differentiate itself from siblings like get_project_items or find_clips, which is the only gap.

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

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

Usage is only implied: 'search by name' versus enumerating with get_project_items, and 'across all bins' hints at scope. There is no explicit when-to-use, when-not-to-use, or named alternative such as find_clips.

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

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

No annotations exist, so the description carries the full load. It discloses what comes back in useful detail (settings, playhead, in/out, all tracks and their clips/flags), which is valuable, but it says nothing about behaviour when no sequence is open, whether the call is expensive on large sequences, or whether data is live versus cached.

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 the resource front-loaded ('Overview of the sequence open in the timeline') followed by the payload inventory in a parenthetical. No filler, no repetition of the tool name.

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 no output schema and no annotations, the description does the work of outlining the return value field by field, which is what an agent needs to decide whether to call it. It falls short only on failure modes and result size, which are the remaining unknowns for a parameterless aggregate read.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Schema coverage is trivially 100% for an empty object.

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?

Specific verb+resource: retrieves an overview of the sequence currently open in the timeline, and it enumerates the payload (settings, playhead, in/out, tracks with clips/muted/locked/targeted). That enumeration distinguishes it in practice from get_sequence_settings, get_track_info and get_playhead, though it never names those siblings explicitly.

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 word 'Overview' implies the orienting use case — grab a single snapshot instead of calling the granular getters — but no when-to-use, when-not-to-use or alternative is stated. An agent must infer that this is the aggregate read versus the per-track/per-setting tools in the sibling list.

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

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

No annotations are provided, so the description must carry the behavioral burden. The verb 'get' and the enumeration of what is included (Motion, Opacity, Volume) make the read-only, bulk-retrieval nature reasonably clear, but nothing is said about permissions, behavior on missing effects, or whether defaults are included when a clip has no effects applied.

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 the resource scope first and the enumerated payload parenthetically attached; no filler. Slight terseness ('incl.') is acceptable but borders on fragmentary.

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 no output schema, the description usefully sketches the return shape (property names, values, keyframes) and clarifies the effects covered, which is enough for an agent to decide to call it. Missing only edge-case behavior and a pointer to narrower sibling tools.

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

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

All three parameters are documented in the schema at 100% coverage, including 0-based indexing rules and the trackType enum, so the description does not need to restate them. It adds no addressing or format detail beyond what the schema provides, which is the baseline 3 case.

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 ('Every effect on a clip') and enumerates the payload (property names, values, keyframes), so an agent can tell it apart from narrow siblings like get_effect_property and get_keyframes. It stops short of naming those alternatives explicitly.

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

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

Usage is only implied by the 'get' framing and the word 'Every' (a bulk read). There is no statement of when to prefer this over get_effect_property or get_keyframes, nor prerequisites such as an active sequence or valid track/clip indices.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the categories of data returned (timing, linked clips, applied effects), which is useful read-operation context, but it does not state whether an active sequence/project is required, error behavior for invalid indices, or return shape.

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 wasted prose. It puts the core purpose and the returned content areas immediately in view.

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

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

For a read tool with no output schema, listing the main returned data categories is helpful but incomplete. It doesn't clarify what 'full details' includes beyond the three named areas, nor how it relates to focused sibling getters that also retrieve clip effects or transform data.

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 all three parameters documented, including the enum for trackType. The description adds only the singular 'one clip' framing and does not add meaning beyond the schema's parameter semantics, so the 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 gives a specific verb and resource ('Full details of one clip') and names the content areas it returns: timing, linked clips, and applied effects. That is clear enough to distinguish it from broad clip-list tools, though it doesn't explicitly separate it from focused siblings like get_clip_effects or get_clip_transform.

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 implies usage for retrieving details of a single clip, but gives no explicit when-to-use guidance, no alternatives, and no exclusions. An agent reading sibling names like get_clip_effects or get_timeline_clips gets no routing help from the description.

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

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

No annotations are provided, so the description carries the full burden. It hints that returned times are in sequence timebase with "(sequence times)", which is genuinely useful, but says nothing about ordering, what marker fields come back, behavior when the clip has no markers, or whether this is read-only.

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 terse parenthetical phrase with zero padding and the key scoping detail up front. It is efficient, though the brevity borders on under-specification rather than tight writing.

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?

Three required parameters and no output schema mean the description should describe what a marker looks like (name, time, color, comment) and the ordering of results. It offers only "(sequence times)", leaving the return value largely unexplained for a lookup 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 clipIndex, trackType, and trackIndex are already documented with 0-based indexing notes. The description adds nothing about which parameters identify the clip, so 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 phrase "Markers within a clip" identifies the resource (clip-scoped markers) and implicitly distinguishes it from get_markers and get_project_item_markers, but there is no verb and no explicit scope statement, so an agent must infer that this is a read operation returning markers belonging to 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?

No guidance on when to use this versus the several marker siblings listed (get_markers, get_project_item_markers, remove_marker, clear_markers). The agent gets no context or exclusions, only a bare resource label.

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

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

No annotations are supplied, so the description carries the full disclosure burden, and it says nothing about return shape, ordering, or whether clips overlapping versus starting at the time are included. "Under a given time" is ambiguous about whether it means clips at/before the time, spanning it, or beginning there. Read-only nature is only implied by the get_ prefix.

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 short, front-loaded sentence with no filler. It is efficient, though it is terse enough that brevity comes at the cost of the clarifying detail the tool 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 one-parameter read operation with no output schema, the description covers the basic idea but leaves the key semantic ambiguity (which clips count as "under" the time, and against which sequence) unresolved. Adequate but with a clear gap an agent would hit on first use.

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

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

The single parameter has 100% schema coverage and the schema already declares "Seconds" and a minimum of 0, so the baseline is 3. The description's "given time" adds no format or reference-point detail (e.g. sequence-relative vs absolute) 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?

"Clips under a given time on every track" names the resource (clips) and the scope (all tracks at a time position), which is more specific than the bare tool name. It does not distinguish itself from closely related siblings such as get_timeline_clips, find_clips, or get_clip_info, so an agent cannot tell which one to pick 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?

There is no statement of when to use this versus get_timeline_clips or find_clips, and no prerequisites or context (e.g. must a sequence be active, does the time refer to the active sequence's timeline). The agent must infer usage entirely from the tool name and the crowded sibling list.

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

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

With no annotations, the description carries the full burden of behavioral disclosure and does not say this is a read-only operation. It also omits what is returned, error behavior for invalid indices, or whether the values reflect keyframed/animated state. The property list hints at the data domain but provides no 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?

It is a single short sentence with no wasted words, but it is not front-loaded with an action verb and reads as a terse field list. The core purpose is buried in the property enumeration rather than stated first.

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 getter with no output schema and no annotations, the description should explain what is returned and that it is a safe read. It provides only a partial field list and leaves the agent to infer return shape and behavior. This is insufficient for correct invocation without inspecting the schema and name.

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 trackIndex and clipIndex are already fully documented in the schema, including 0-based indices and V1/A1 conventions. The description adds no parameter information beyond the schema, which is the baseline 3 case.

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 lists the transform properties (x, y, scale, rotation, anchor, crop, opacity) but never states the action, such as 'retrieves' or 'returns'. The name implies a getter, but the description alone reads as a field inventory rather than a clear verb+resource purpose. It does not differentiate from the sibling set_clip_transform.

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 on when to use this tool versus alternatives like get_clip_info or set_clip_transform. The agent must infer from the name that this reads transform values. No prerequisites, conditions, or exclusions are mentioned.

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

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

With no annotations, the description bears the full burden, and it does disclose that the return includes volume in dB plus keyframes and L/R levels 'if present' — useful signal that fields are optional. It does not mention error conditions (e.g., non-audio clips), permissions, or whether volume is read pre- or post-fader.

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 compact clause, front-loaded with the primary return value before the optional extras. It is terse to the point of being a sentence fragment, but nothing is wasted.

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 2-parameter read with full schema coverage and no output schema, the description adequately signals the payload contents. It stops short of clarifying what happens when the clip is not audio or how volume relates to fades/channel volumes, which the sibling tools make relevant.

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%, with both required parameters documented (trackIndex is 0-based A1=0, clipIndex is 0-based referencing get_timeline_clips). The description adds nothing beyond the schema, 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 identifies a specific resource (audio clip volume) and the unit returned (dB), plus optional extras (keyframes, L/R channel levels). It does not explicitly distinguish itself from get_track_volume or set_clip_volume, but the clip-vs-track and read-vs-write distinction is inferable from the name.

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 statement of when to call this versus alternatives such as get_track_volume (track-level) or set_clip_volume (write counterpart). Usage is only implied by the 'get_' prefix; nothing tells the agent about prerequisites or exclusions.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing. "Read" weakly implies a non-mutating call, but there is no mention of what is returned (current value only, or keyframes/min-max too), what happens when the effect or property name doesn't match, or whether index-based vs name-based lookup behaves differently.

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

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

Four words, front-loaded and waste-free, but this is under-specification rather than conciseness. The brevity leaves obvious gaps that a single additional sentence could close, so it earns a middling score rather than top marks.

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?

A five-required-parameter read tool with no annotations and no output schema needs the description to explain the return shape and the effect-property lookup model; it explains neither. An agent must infer entirely from the schema and sibling names what a successful result looks like.

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 every parameter is documented in the schema, including the string-or-index union for 'effect' and 'property' and the 0-based conventions. The description adds no meaning beyond that, 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?

"Read one effect property" gives a verb and a resource, but the resource is underspecified: it never says the property lives on a clip effect, nor that the read is scoped by track/clip. It also does not distinguish itself from nearby siblings like get_clip_effects (which also exposes property data) or get_clip_transform.

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 when-to-use guidance at all: no statement that get_clip_effects should be called first to enumerate effects/properties, no exclusion against get_clip_transform or get_keyframes. The schema's param descriptions hint at get_clip_effects as a prerequisite, but the description itself offers nothing.

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

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

With no annotations at all, the description carries the full burden. It does disclose two real traits: output is just names (not effect objects with properties) and the unfiltered lists are long, implying the caller should narrow the query. It says nothing about permissions, project prerequisites, or whether results are project-scoped or application-global.

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 plus a parenthetical rationale, with no wasted words. Terseness borders on fragmentary ('Names of available...' has no verb), but every element carries 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 lookup with no output schema, stating that the return value is names is the key missing piece and it is present. However, nothing explains which kind values yield which catalogs or whether a project context is required, leaving gaps an agent must discover at runtime.

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

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

Schema coverage is 50%: 'filter' is documented in the schema, while 'kind' is only an enum with no prose. The description's 'effects or transitions' does map onto the kind enum's effect-vs-transition split and reinforces why a filter is needed, but it doesn't explain the video/audio axis of the enum.

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

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

States the resource and result precisely: a catalog of available effects or transitions, returning names. 'Available' distinguishes it from applied-item tools like get_clip_effects or get_transitions, though the description never names those siblings explicitly.

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