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

With no annotations provided, the description carries the full behavioral burden, and it delivers: it discloses that tracks are created automatically when missing, that the default placement is at the end of the track, and that Resolve can shorten a still, so the returned actual_duration_frames should be checked. It also explains the meaning of pan, tilt, zoom, and opacity in terms an agent can act on.

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

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

The description is front-loaded with the core action and use cases, then branches into placement and parameter semantics. Every sentence carries useful information, and none of it is filler or repetition of the schema.

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

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

The description is remarkably complete for a 12-parameter tool with no annotations and zero schema descriptions, covering use cases, placement rules, parameter meanings, and a verification step. It is slightly incomplete around the semantics of record_frame and how duration_frames and duration_seconds interact, which an agent might need to know for advanced calls.

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 prose must compensate; it meaningfully explains pan_percent, tilt_percent, zoom, opacity, at_playhead, track_index, and implies track creation behavior. However, it leaves gaps for record_frame, rotation, and the precedence/interaction between duration_frames and duration_seconds, which are not self-explanatory from titles alone.

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

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

The description opens with a specific verb and resource: 'Put an image on the timeline:' and explains the workflow of importing, placing with duration, and positioning. It further distinguishes itself by naming concrete use cases like logos, screenshots, overlays, and title cards, which separates it from sibling tools like insert_title or import_media.

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

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

The description gives clear context for when to use the tool, explicitly calling it 'the tool for logos, screenshots, overlays, title cards, and any generated picture.' It also provides operational guidance such as using track_index=2 or higher for overlays and setting at_playhead=True to place at the playhead, but it does not explicitly name alternatives or state 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 of behavioral disclosure. It does reveal useful behavior: frame is relative to timeline start and omitting frame defaults to the current playhead. Still, it does not describe effects on existing markers, required timeline state, or any failure behavior, leaving moderate gaps.

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

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

Two sentences convey the core action and a critical parameter nuance with zero wasted words. The key action is front-loaded, and the frame guidance is compressed into a single efficient clause.

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

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

For a straightforward 5-parameter tool with an output schema, the description covers the purpose and the trickiest parameter, frame. It lacks guidance on the meaning or valid values of color, duration, and note, and does not state any context requirements. This is adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must add meaning to the five parameters. It explicitly explains frame, but name, note, color, and duration are left entirely to inference from their property names and defaults. This is insufficient for a tool with five parameters, even though the frame explanation is valuable.

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

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

The description immediately states the action and resource: 'Add a timeline marker.' This is a specific verb and object that clearly distinguishes the tool from siblings like delete_marker and add_track, leaving no ambiguity about its function.

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

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

The description provides clear context on when to omit the frame parameter ('use the current playhead'), which is helpful parameter-level guidance. However, it does not explicitly state when to choose this tool over alternatives or mention any exclusions or prerequisites, so tool-selection guidance remains implied.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It says tracks are empty and lists track types, but it does not mention where tracks are added, whether this is destructive or reversible, or what side effects occur.

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

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

Two short sentences with no wasted words. The core action is front-loaded, and the track_type clarification 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 simple two-optional-param mutation with an output schema, the core action and key parameter meaning are covered. However, the description does not specify the target context, such as the active timeline, or any operational conditions, leaving the agent to infer them.

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% property description coverage, but the description adds real value by enumerating valid track_type values. 'count' is not explicitly described, but its meaning is self-evident from 'Add one or more' and the schema default of 1.

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 on a specific resource: adding one or more empty tracks, and it narrows track_type to video, audio, or subtitle. This clearly distinguishes it from sibling tools like add_image, add_marker, or set_track_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?

No guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites such as needing an open timeline. The description only restates what the tool does without routing the agent to the right context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that the effect is time-based and implemented via Fusion, but it does not explain whether existing color grades are overwritten, whether repeated calls stack, what the frame range semantics are, or whether the operation is reversible. For a mutating tool with zero annotation coverage, this is a notable gap.

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

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

The description is a single front-loaded sentence with no filler. It opens with the core verb and resource, then adds specific effect details and the Fusion mechanism in a compact parenthetical.

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

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

For a tool with 10 parameters, no annotations, and no parameter-level schema descriptions, the description is too sparse to be complete. It does not explain frame-range behavior, how saturation/tint_strength interact with the animation, or what happens to existing clip color settings. The presence of an output schema covers return values, but not these usage-critical details.

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, but it only implicitly maps to rainbow/flicker parameters and leaves item_id, start_frame, end_frame, saturation, tint_strength, and the numeric tuning parameters unexplained. Ten parameters exist, and the description adds meaning for only a couple of them.

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

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

The description states a specific action ('Animate dynamic color effects') on a specific resource ('a clip') with specific techniques ('rainbow hue rotation and subtle organic luminance flicker') and the mechanism ('via Fusion'). This clearly distinguishes it from siblings like animate_zoom, keyframe_clip_saturation, and set_clip_color.

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 this tool is for time-based color animation via Fusion, which gives some context, but it never explicitly states when to choose this over alternatives such as set_clip_color or keyframe_clip_saturation. There are no exclusions or conditions provided.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It explains supported directions, easing curves, keyframes, and presets, which is useful, but it does not state whether the operation overwrites existing clip keyframes, mutates the timeline, or requires a particular clip selection. 'Animate' implies a state change but the consequences are left implicit.

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 tightly written, front-loads the core purpose, and then enumerates only the option values an agent needs to know. The easing and preset lists are long but directly useful because the schema provides no enums or descriptions.

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

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

Despite an output schema, the tool is complex with 13 optional parameters, no annotations, and 0% parameter description coverage. The description fails to explain several operational aspects an agent needs to call the tool correctly, especially the keyframe array structure, coordinate system, and reset behavior.

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

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

Schema description coverage is 0%, so the description must compensate. It does add value for direction, easing, and preset values, but it leaves major parameters unexplained: reset, item_id, track_index, start_zoom/end_zoom semantics, start_frame/end_frame relationships, target_center_x/y coordinate meaning, and the required shape of keyframe objects. This is a significant gap for a 13-parameter 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?

The description opens with a specific verb and resource: 'Animate a clip's scale and framing over time.' It distinguishes itself from static transform tools like set_clip_transform by emphasizing animation over time, and names concrete use cases (smooth zooms, punch-ins, rebounds, pull-outs, multi-keyframe paths).

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 first sentence clearly establishes the usage context: this is for animating scale/framing over time rather than setting a static transform. It does not explicitly name alternatives or exclusions, but the context is unambiguous and the supported modes are clearly listed.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the core mutation and that omitting track_index/record_frame appends at the end of the timeline. However, it does not mention side effects like automatic track creation or what occurs if both paths and media_ids are 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 description is tight: two sentences with zero filler. The main purpose is front-loaded, followed by an actionable usage tip and a clear pointer to the relevant alternative.

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

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

The description covers the primary use case and the key deviation from add_image, but it is not fully complete for a no-annotation tool with 5 parameters. Missing context around create_track and source-required semantics leaves an agent guessing on edge-case invocations.

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. It does clarify that track_index and record_frame can be omitted to append at the end and that sources can be paths or media_ids. Yet it leaves create_track's meaning unexplained and does not state whether at least one source is required.

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

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

The description names a specific verb ('append'), a clear resource ('timeline'), and the accepted source types ('media pool ids or absolute file paths'). It also distinguishes itself from 'add_image' by explicitly reserving stills for that sibling tool. This makes the tool's purpose immediately distinguishable.

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

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

The description explicitly says to use 'add_image' instead for still images, and explains when track_index and record_frame should be omitted. It does not, however, explain when to choose this over import_media or whether media already needs to be in the media pool.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects, reversibility, or any consequences for the timeline. It also doesn't specify whether the operation is permanent or what happens to existing effects. For a mutating operation, 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?

The description is a single, concise sentence with no wasted words. It front-loads the primary purpose without elaboration. Length is appropriate for stating the core function, and structure is 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?

Given the tool's high complexity (19 parameters, no annotations, no schema descriptions), this description is far from complete. It does not explain parameter dependencies, how to set a gradual blur, what the output schema returns, or any usage context. An agent would struggle to correctly invoke this tool based solely on the description.

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 0% schema description coverage and 19 parameters, the description must compensate but does not. It hints at 'dynamic' (relating to animate) and 'masked' (relating to mask_shape) but never maps these to actual parameters. An agent cannot infer parameter semantics from the description alone, and the schema provides only titles and defaults, leaving meaning unclear.

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

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

The description clearly states the action (apply), the resource (blur effect), and the scope (static or dynamic, full frame or masked bounding region) on a timeline clip. It is specific enough to distinguish from other effect tools like animate_zoom or animate_color_fx, which are listed as siblings. The verb and modifiers leave little ambiguity about what the tool does.

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

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

There is no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or mention sibling tools at all. An agent would have no idea when to choose apply_blur_effect over other effects. This is a 'no guidance' case.

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

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

With no annotations provided, the description carries the full burden, and it does well: it discloses non-destructive behavior ('new duplicate timeline, retaining the original'), a consent requirement, and data-loss risks ('does not guarantee preservation of fades, gain automation or all metadata'). This goes well beyond what the schema reveals.

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 sentences, front-loaded with the main behavior, followed by necessary constraints and caveats. There is no filler; each sentence adds operational value.

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

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

The description covers scope, exclusions, approval requirements, and risk profile, and an output schema exists so return-value documentation is not needed. The main gap is parameter mapping, but the meaning of the required marker_ids is reasonably inferable from the phrase 'selected cuts.'

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% and the description never names marker_ids or the optional name parameter. It vaguely connects to parameters via 'USER-ACCEPTED silence intervals' and 'selected cuts,' but doesn't explain what the IDs refer to, how approval is represented, or what the optional name controls. The agent is left to infer the required argument's meaning and format.

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

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

The description opens with a specific verb-resource pairing: 'Remove USER-ACCEPTED silence intervals on a new duplicate timeline, retaining the original.' This clearly distinguishes it from review/silence tools like review_silence and from marker-editing tools like delete_marker, while also stating its non-destructive nature.

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

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

It gives explicit applicability constraints: only an isolated normal-speed dialogue clip or one aligned video/audio pair, and explicitly rejects complex timelines, Fusion clips, changed timelines, and mixed frame rates. It also states the prerequisite of explicit user approval. It does not name an alternative tool, but the when/when-not conditions are strong.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'dynamic or static', 'feathering', 'ambient darkness', and 'animated sweep keyframes', but it does not disclose whether applying the mask overwrites existing effects, whether it modifies the source item, or what side effects or state changes occur. For a mutation-like tool with 21 parameters, this is a significant transparency gap.

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

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

The description is a single, front-loaded sentence with no filler, and it communicates the core purpose plus several key behavior features efficiently. Its brevity is a virtue, though given the parameter count it could be somewhat more structured without becoming 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?

With 21 parameters, no parameter descriptions, no annotations, and no usage guidance, a one-sentence description is grossly insufficient. An agent cannot know the meaning of most parameters, the coordinate systems, frame semantics, or what 'dynamic' versus 'static' requires. The output schema does not compensate for the missing input semantics.

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

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

Schema description coverage is 0%, and the description only hints at a few parameters: feathering maps to soft_edge, ambient darkness maps to ambient_brightness, and animated sweep keyframes maps to keyframes/animate. It provides no meaning for shape, width/height, center_x/center_y, start/end radius, start/end frame, track_index, or mask_name, leaving most of the 21 parameters semantically unexplained.

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

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

The description uses a specific verb ('Apply') and resource ('spotlight reveal mask'), and characterizes it as dynamic or static with adjustable feathering, ambient darkness, and animated sweep keyframes. This clearly identifies the tool and differentiates it from sibling effect tools like apply_blur_effect, animate_zoom, or keyframe_clip_saturation.

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

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

No guidance is given about when to choose this tool over alternatives, what input context it requires (e.g., selected clip/timeline), or when the dynamic versus static options should be used. The description implies a spotlight effect but never states exclusions or conditions that would help an agent route correctly.

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

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

With no annotations provided, the description carries the full burden. It goes beyond a simple statement of function by adding context about a key limitation (API presence vs. operation success) and clarifies the execution environment (Console worker in Resolve Free). This gives the agent important behavioral insight beyond the basic purpose.

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

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

The description is concise, with the core purpose in the first sentence. The additional sentence adds valuable context about limitations and execution environment without unnecessary detail. It's well structured and front-loaded.

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

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

Given the tool has 0 parameters and no output schema, the description is fairly complete in what it does, but it doesn't describe the return format or structure of the report. Since it reports multiple items, the agent might need to know how results are presented (e.g., object keys, boolean flags). The description could be more explicit about the output structure.

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

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

The tool has 0 parameters, so the schema provides no semantics to cover. The description fully compensates by specifying what is reported (version, transport, API presence, decoder availability). With no parameters to explain, baseline 4 is appropriate.

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

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

The description clearly states it reports on Resolve version, transport, API presence, and source decoder availability. The verb 'report' and the listed items distinguish it from siblings like resolve_status, which likely focuses on current status, and project_info. It could be more specific about what 'transport' entails, but it's clear enough.

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

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

The description provides clear context: it explains that API presence doesn't guarantee successful operations, and that new review workflows use ordinary timeline APIs and work through the Console worker in Resolve Free. This helps the agent understand when to use this tool, though it doesn't explicitly state when not to use it or name alternatives.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well. It discloses that existing Fusion connections are preserved, timeline duration and linked audio remain unchanged, speed 1.0 neutralizes only bridge-owned nodes, reverse is not verified, and clip_attributes mode affects every use of the source media. This gives an agent an unusually complete picture of side effects and limitations.

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 longer than average, but every sentence earns its place given eight parameters and two behavioral modes. It front-loads the core purpose, then states side effects, mode-specific behavior, and parameter semantics in a logical order. The examples are repetitive only in the sense that they deliberately disambiguate the four speed-specification parameters.

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

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

The description covers behavior, side effects, method selection, defaults, and limitations, which is strong for a tool with no annotations. The main gap is that it does not state what happens if multiple speed parameters (speed, speed_percent, slow_down_percent, speed_up_percent) are supplied simultaneously, which is a plausible ambiguity an agent could hit when constructing arguments.

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

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

The input schema has no parameter descriptions, but the Args block fully compensates by explaining each parameter with concrete examples and conversions, e.g. 'slow_down_percent: 25.0 to slow down by 25% -> 0.75x speed.' It also clarifies defaults like item_id defaulting to 'playhead' and interpolate_frames defaulting to True, adding meaning far beyond the raw schema.

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

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

The description opens with a specific verb and resource: 'Change constant video speed through a bridge-owned Fusion TimeSpeed node.' It further clarifies the two implementation modes (fusion vs. clip_attributes), which distinguishes this tool's behavior from other editing tools and prevents conflation with generic clip-property setters.

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

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

The description gives clear contextual guidance, such as 'Clip-attributes mode changes EVERY use of the source media' and 'Reverse must be False; use Resolve manually for reverse playback.' It does not explicitly compare against sibling tools like set_clip_property, but it does explain when each internal method is appropriate and states a firm exclusion for reverse playback.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the operation is non-destructive ('without changing the active timeline') and defines the exact scope of comparison, including exclusions like pixels, Fusion graphs, grades, and Fairlight. It does not discuss auth or rate limits, but for a read-only comparison this is a strong disclosure.

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

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

The description is two sentences with no redundancy. The first sentence front-loads the core purpose and safety guarantee; the second efficiently clarifies scope and exclusions. 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 read-only comparison tool with an output schema present, the description covers purpose, non-destructive behavior, comparison scope, and exclusions. The only significant gap is parameter-level semantics (ID vs name format for original/preview), but overall the description is sufficient for an agent to invoke the tool correctly in most 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 0%, so the description must compensate for the 2 undocumented parameters. It adds meaning by saying comparison is 'by unique ID or exact name' and names the parameters 'original' and 'preview,' but it does not specify which parameter accepts an ID versus a name, what format is expected, or how exact-name matching works. This leaves some ambiguity for the agent.

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

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

The description clearly states a specific verb ('Compare') and resource ('two timelines'), and adds precise scoping: 'by unique ID or exact name without changing the active timeline.' This distinguishes it from other timeline-related sibling tools like timeline_overview, preview_timeline, or set_playhead.

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

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

The description provides clear context for when to use this tool: comparing two timelines and getting structural/property/marker changes. It also explicitly states what the tool does not compare, which helps avoid misuse, though it does not name alternative sibling tools or provide explicit when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it mostly restates parameter mechanics. It does not disclose side effects such as what happens to the original timeline items, whether selection is required, whether the operation is reversible, or what side effects occur on the timeline. The word 'create' implies mutation, but the actual behavioral consequences beyond creating the clip are not disclosed.

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

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

The description is efficient and front-loaded with the main purpose, followed by a compact Args section. Each parameter line earns its place by adding examples or clarifying defaults, though the formatting is slightly verbose and largely mirrors the schema fields.

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

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

The description covers all parameters and provides useful examples, and an output schema exists so return values need not be explained. However, with no annotations, the tool lacks context around practical usage context, prerequisites, and behavioral side effects, leaving an agent with partial information about the full impact of the operation on the timeline and its items.

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, and it does: it explains item_ids as a list, item_id as a single id with 'playhead' default, name as the new clip's name, and start_timecode as an optional custom timecode. It also adds examples and clarifies the fallback behavior when item_ids is omitted, which is essential and not present 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?

The description states a specific action and resource clearly: it 'create[s] a compound clip combining one or more timeline items into a single container clip.' This is a specific verb+resource statement that distinguishes the tool from sibling tools like split_clip or delete_clips, which address different timeline editing operations.

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

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

The description implies the use case through 'combining one or more timeline items into a single container clip', and explains the distinction between item_ids and item_id with a fallback rule. However, it does not explicitly state when to choose this over alternatives or mention prerequisites such as having a timeline open or whether it replaces the original items.

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 reveals that the tool creates and opens a timeline and that the timeline starts empty, but it does not disclose behavior around name collisions, whether opening changes the current workspace context, or whether the operation can fail or overwrite existing timelines.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes: 'Create and open' specifies the action, 'new empty' scopes the resource state, and 'exact name' clarifies parameter semantics.

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 low-complexity with one parameter and an output schema, so return format details are already covered. However, the description omits edge-case behavior around duplicate names, workspace switching, and failure conditions, which an agent would benefit from knowing before invoking the tool.

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

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

Schema description coverage is 0%, so the description must compensate. It adds the meaningful qualifier 'exact name,' indicating the provided string is used verbatim, but it does not explain name constraints such as uniqueness, length, or allowed characters. The parameter itself is simple enough that this partial guidance is marginally sufficient.

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

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

The description clearly states a specific verb-resource pair: 'Create and open a new empty timeline.' It distinguishes this from sibling tools like open_timeline or list_timelines by emphasizing 'new empty,' so an agent can select it correctly without opening the schema.

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

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

The description implies the tool is used when a new timeline must be created and opened, but it does not explicitly state when not to use it or mention alternatives such as open_timeline for existing timelines. The usage context is inferable but not spelled out.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that the operation is destructive and that it enforces user approval within the conversation. This adds meaningful behavioral context beyond simply stating 'Delete'. It does not mention ripple behavior or undo, but the core safety behavior is covered.

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

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

Two sentences with no waste. The core action is front-loaded, and the critical approval requirement is stated immediately. 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 destructive tool with no annotations and three parameters (including a boolean 'ripple' that modifies behavior), the description is too sparse. It does not cover the ripple parameter's effect, how to supply approval via user_approved, any side effects, or output specifics. An agent would struggle to call this correctly without inspecting the schema or 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?

Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It does not explain item_ids, ripple, or user_approved. The approval requirement is implied but not connected to the user_approved parameter. With three parameters and zero schema docs, this is a significant gap that could lead to misparameterization.

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 'Delete timeline items' uses a specific verb and resource, clearly distinguishing it from sibling 'delete_marker' which targets markers. The scope is unambiguous and immediately understandable.

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 states a critical usage constraint: it refuses unless the user explicitly approved the destructive action in the current conversation. This gives clear context on when the tool can be invoked. It does not mention alternatives, but the only close sibling (delete_marker) is distinct enough, so no explicit direction is 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 of behavioral disclosure. It correctly indicates a destructive action, but it omits important behavioral details such as irreversibility, behavior when no marker exists at the frame, and behavior when multiple markers share the same frame.

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 efficient sentence with no filler. The verb and object are front-loaded, and every phrase adds relevant operational detail.

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

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

Given the simple one-parameter tool and existing output schema, the description is mostly adequate. Gaps around missing markers, multiple markers at the same frame, or destructive consequence are left unaddressed, so a cautious agent still lacks some operational edge-case context.

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

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

The schema defines frame only as an integer with 0% coverage, so the description must add meaning. It adds the crucial semantic that frame is measured relative to timeline start, which meaningfully helps an agent provide a correct value.

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

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

The description uses a specific verb ('Delete the timeline marker') and a precise location ('at a frame relative to timeline start'), making the resource and target unambiguous. It also naturally distinguishes itself from the sibling add_marker tool.

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

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

The intended use is implied by the delete verb and marker resource, so an agent can infer when it applies. However, it never explicitly states when to use it over alternatives, edge conditions, 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It communicates a non-mutating inspection operation, but does not explain behavior for clips with no grading nodes or Fusion compositions, potential latency, or any prerequisites. This is minimal behavioral context for a tool with zero annotation support.

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

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

The description is a single sentence front-loaded with the action and resource, with no filler or redundant wording. Every phrase contributes semantic content.

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

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

The tool is simple with one required parameter and an output schema, but the description omits guidance on item_id provenance, when to choose this over set_clip_grade, and expectations for clips without grade data. With no annotations, the description leaves an agent without enough context to confidently call the tool in varied situations.

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 description does not mention item_id at all or clarify its format, provenance, or what constitutes a clip item. Since the schema provides no parameter documentation and the description does not compensate, an agent gets no added meaning beyond the bare property name.

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

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

The description uses the specific verb 'Inspect' and names the exact resource ('color grading nodes, versions, and Fusion compositions on a clip'). This clearly distinguishes the tool from write-oriented siblings like set_clip_grade and from unrelated clip operations such as 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?

The inspect verb implies this is the read-only tool for grading data, but the description provides no explicit when-to-use guidance, exclusions, or comparison with alternatives. The contrast with set_clip_grade is present in the sibling list but not in the description itself, so usage guidance remains implicit.

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 burden. It states the tool reads (non-destructive) and implies no side effects, but does not detail return format or error conditions. It provides some behavioral context but not comprehensive disclosure.

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

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

The description is two sentences with no filler. The core purpose is front-loaded, and the parameter hint is directly relevant. 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?

With output schema, the tool is well-specified for a simple getter. However, the lack of guidance on when track_index is needed and the absence of any note about prerequisites (e.g., must have a timeline open) leaves some room. Overall, adequate for typical use but not exhaustive.

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. It explains item_id (including 'playhead' special value) but says nothing about track_index, which is arguably a critical disambiguation parameter when multiple clips share an ID. This is a significant 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 clearly states the tool reads the current position, scale, rotation, crop, opacity, and blend mode of one timeline item. It distinguishes itself from siblings like set_clip_transform and get_clip_grade by specifying the exact properties it reads. The verb 'read' indicates a non-mutating operation.

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

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

The description explains how to use the item_id parameter, including the special value 'playhead' to target the clip under the playhead. It does not explicitly state when not to use it or mention alternatives, but the context is clear enough for an agent to know when to call it versus a setter tool.

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

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

Annotations are absent, so the description carries the behavioral burden. It clearly states what the tool does (imports to the Media Pool), the required input nature (existing local files, absolute paths), and a key non-behavior ('does not place them on the timeline'). This is meaningful beyond the bare tool name, though it does not address edge cases like duplicates or invalid paths.

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

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

The description is two concise sentences with no filler. The main action is front-loaded, and the important exclusion is stated immediately after.

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

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

For a simple one-parameter import operation with an output schema, the description covers the essential behavior and the key boundary condition. It does not explicitly mention duplicate handling, supported formats, or where in the Media Pool the import lands, but these are minor for this tool's primary use case.

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 schema only exposes an array of strings named 'paths'. The description compensates by explaining that the tool takes absolute paths to existing local media files, giving crucial semantic meaning not present in the schema. It is somewhat minimal but sufficient for this single-parameter 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?

The description states a clear verb ('Import'), the resource ('existing local media files ... into the Media Pool'), and the required input form ('by absolute path'). It also explicitly contrasts the action with a related outcome ('does not place them on the timeline'), which clearly differentiates it from timeline-adding siblings.

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

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

The description gives clear context for when to use the tool: to get local files into the Media Pool without adding them to the timeline. It does not explicitly name alternative tools such as append_media or add_image, but the 'does not place them on the timeline' statement effectively signals that timeline placement would require a different 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 carries the full burden and does a solid job: it warns that insertion is "best effort," says title names depend on Resolve version/templates, and explains that text setting may not be supported and to check "text_set" in the result. It does not cover side effects like track selection failure or opacity semantics, but the disclosed failure modes are genuinely useful.

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

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

The description is three sentences with no filler. The core operation is front-loaded, followed by the most important caveats and an alternative. Each sentence contributes useful 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 3-optional-parameter tool with no annotations, the description covers the important environmental caveats (version-dependent templates, text-scripting fallback) and points to a better alternative for animated typography. The main omissions are opacity semantics and any explicit note about prerequisites or failure behavior beyond text_set, but an output schema exists and the description is otherwise sufficient.

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?

At 0% schema-description coverage, the description must compensate for the schema. It adds meaning for title_name (version/template dependent; Text+/Text common) and for text (scripting support varies; check text_set). However, opacity is never mentioned, including its scale or valid range, which is a real 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 clearly states the operation: "Insert a title at the playhead on the current video track, best effort." This is a specific verb and resource. It does not explicitly differentiate itself from sibling tools such as add_image or add_track, instead naming Remotion as an external alternative, so it falls just short of full differentiation.

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 provides concrete guidance on when not to use the tool: "For designed animated typography, Remotion produces a better result." It also sets expectations about title-name availability across versions and templates. It does not enumerate exclusions among the listed sibling tools, but the context is clear.

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

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

With no annotations, the description carries the transparency burden. It discloses the core behavior (gradual transition across frames via a BezierSpline), which adds value. However, it does not state whether existing keyframes are overwritten, whether it mutates the clip in place, or what limitations apply.

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

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

The description is one efficient sentence with no filler. The core action is front-loaded, the example is useful, and every clause earns its place.

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

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

For a mutation tool with five parameters and no annotations, the description is thin. It lacks usage context, does not clarify the meaning of a null end_frame, and gives no indication of side effects on existing animation. The output schema exists but is not shown, so the description still needs to cover the invocation essentials more completely.

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. It does add meaning by illustrating start and end saturation values (1.0 to 0.0) and the notion of 'across frames', which maps to start_frame/end_frame. But it does not explain item_id, the null end_frame default, or frame units/behavior.

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

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

The description states a specific verb ('Animate'), a clear resource (clip color/saturation), and a concrete method ('Fusion BezierSpline on the clip'). The example '1.0 full color to 0.0 black and white' makes the saturation focus obvious, though it does not explicitly name or contrast sibling tools like animate_color_fx.

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

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

No guidance is given for when to use this tool versus alternatives. The description only says what it does; it does not mention prerequisites, when-not-to-use, or distinguish itself from related tools such as set_clip_grade or animate_color_fx.

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 adds useful context by specifying that items are listed recursively and enumerating the output fields (ids, bin paths, file paths, frame counts, durations). However, it does not explicitly state that the operation is read-only or describe any limits, errors, or performance implications beyond the recursive behavior.

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

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

The description is a single, front-loaded sentence that states the action, resource, and then lists the returned attributes. It is efficient and contains no filler. The only minor improvement would be to structure the attribute list more visually, but it is already clear and compact.

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 (one optional parameter, output schema provided), and the description covers the core purpose and return contents. It does not explain the 'limit' parameter, which is undocumented in the schema, and lacks explicit usage conditions. Still, for a straight read-only listing operation with an output schema, it is nearly complete but leaves the parameter behavior unexplained.

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

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

The schema has 0% description coverage for the single 'limit' parameter, so the description must compensate. It does not mention 'limit' at all—neither its meaning, effect on results, default value, nor how it interacts with recursion. This is a significant gap for an agent trying to understand and set the parameter correctly.

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

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

The description states a specific verb ('List'), a clear resource ('media pool items'), and a precise scope ('recursively'), and enumerates the returned fields. This differentiates it from the sibling 'list_render_presets' by naming a distinct resource, so an agent can select it correctly without opening the schema.

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

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

The purpose inherently implies usage (call when you need to enumerate media pool items), but the description provides no explicit when-to-use guidance, prerequisites, or exclusions. It does not name alternative tools for similar tasks, so the guidance is only implied by the verb and resource.

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

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

With no annotations provided, the description carries the behavioral burden, and 'List' clearly indicates a read-only operation. It adds the useful scoping detail 'available in this project' and clarifies that results are meant to feed into render_current_timeline. Return-format details are unnecessary because an output schema exists.

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

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

The description is a single, well-formed sentence that front-loads the action and resource, then adds the crucial workflow connection. Every word earns its place with no redundancy or filler.

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

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

For a zero-parameter listing tool with an output schema, this description is complete. It states the resource scope, the project context, and the intended consumer tool, giving an agent everything needed to select and invoke it correctly.

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

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

The tool has zero parameters and 100% schema coverage, so there is nothing for the description to document. The description focuses on what the tool returns rather than inputs, which is appropriate for a parameterless listing 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?

The description uses a specific verb ('List') and resource ('render presets and formats available in this project'), making the tool's purpose immediately clear. It also names the related render_current_timeline tool, helping distinguish this listing operation from the rendering operation.

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

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

The phrase 'for use with render_current_timeline' provides clear contextual guidance: this tool should be called to discover available presets before rendering. It does not explicitly state when not to use it, but there are no plausible alternatives among the siblings for this task.

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 states the read-only action ('List') and reveals an additional behavioral trait (identifying the current timeline). It does not explicitly confirm non-destructiveness or side-effect freedom, but the verb 'List' implies a safe query, and it adds the scoping context of the open project.

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

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

A single sentence with no filler: it states exactly what the tool does and what it identifies. Every word contributes, and the main action is front-loaded.

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

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

Given the tool's simplicity (no parameters), the presence of an output schema, and the clear description, the definition is complete. An agent knows what the tool does, what scope it operates in, and that it provides the current timeline in the 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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific meaning because there are none, but it does clarify the operation's scope ('in the open project'), which is relevant for an agent understanding what the tool acts on.

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

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

The description uses a specific verb 'List' with a clear resource 'every timeline in the open project' and adds a distinctive behavior 'identify the current one'. This distinguishes it from siblings like timeline_overview or open_timeline, as it enumerates all timelines and marks the active one.

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

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

The description provides clear context: use this when you need a complete enumeration of timelines and the current one. However, it does not mention alternatives or exclusion cases (e.g., when to use timeline_overview instead), so it stops short of explicit when-not guidance.

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

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

With no annotations, the description carries the behavioral burden. It transparently describes that this tool changes the active page/window and lists the supported pages, which is the key behavior an agent needs to know. It does not mention side effects or prerequisites, but for a simple UI navigation action the disclosure is strong.

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

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

A single, tightly worded sentence that front-loads the core action and packs the valid options into a compact list. There is no filler or repetition of schema 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 one-parameter UI navigation tool with no annotations, the description covers everything needed to invoke it correctly: the action, the target, and the accepted page values. The presence of an output schema further reduces the need to document return behavior.

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

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

The schema provides only a bare string parameter with 0% description coverage and no enum, so the description must compensate. It does so by enumerating the valid page values: media, cut, edit, fusion, color, fairlight, and deliver. This is meaningfully more than the schema alone provides, though it stops short of explicitly saying these are the only accepted values.

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

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

The description clearly states a specific action ('Switch the Resolve window to a page') and enumerates the exact page targets. This distinguishes it from most sibling tools, which operate on timelines, clips, or media rather than the visible workspace.

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

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

The intended use—navigating the Resolve UI so the user can view a change—is implied clearly by the description. However, it gives no explicit guidance on when not to use it or which sibling tool to choose instead, so an agent is left to infer the boundary from the action 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?

With no annotations present, the description carries the full burden of behavioral disclosure, yet it only says 'open' without explaining whether the tool changes the active timeline, has side effects, or fails on invalid identifiers. The one-based index detail is a useful behavioral nuance, but the overall side-effect profile is absent.

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. Every element—the action, the addressing modes, and the source list—earns its place and directly supports invocation.

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

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

An output schema exists, so return values need not be spelled out. Still, the description leaves open how identifier parameters should be selected or combined, and what 'open' does behaviorally in a suite with timeline_overview and preview_timeline. It is minimally viable but not fully 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?

Since schema description coverage is 0%, the description adds real meaning by mapping 'unique ID', 'exact name', and 'one-based index' to the three parameters and grounding index in list_timelines. However, it does not state whether the parameters are mutually exclusive, which one takes precedence if multiple are provided, or whether at least one must be supplied despite all being optional 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?

The description clearly identifies the action as 'Open a timeline' and specifies three addressing modes: unique ID, exact name, or one-based index. This distinguishes it from list_timelines and create_timeline, though it does not contrast it with sibling tools like timeline_overview or preview_timeline, leaving the exact meaning of 'open' somewhat under-specified.

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 list_timelines' implies a prerequisite workflow and grounds the identifier values, but the description does not explicitly state when to prefer this tool over related siblings such as timeline_overview or preview_timeline. It also gives no exclusion criteria or when-not-to-use guidance.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states 'No edits are applied by this call,' which prevents an agent from assuming it is a destructive operation, and it discloses that a duplicate is opened while the original is retained. This is useful context beyond the schema.

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

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

The description is concise and front-loaded: the first sentence states the core action and purpose, and the second adds a non-destructiveness guarantee plus a short workflow. Every sentence earns its place 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?

The description covers the workflow and safety guarantee well, but it omits any explanation of the optional 'name' parameter and does not mention prerequisites such as an already-open active timeline. It is sufficient for a no-argument call, but not fully complete for agents that may want to supply the optional parameter.

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 one optional parameter, 'name', with no description and no description coverage in the tool description. The description never mentions this parameter, so an agent cannot know whether 'name' refers to the preview timeline's name or something else. This is a clear gap, even though the parameter 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?

The description clearly states the action: 'Duplicate and open the active timeline for reviewing edits while retaining the original.' This is a specific verb + resource + purpose, and it naturally differentiates the tool from siblings like open_timeline by emphasizing duplication and non-destructive review.

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

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

The description gives an explicit workflow: get fresh clip IDs with timeline_overview, edit the preview, then use compare_timelines before accepting. It clearly explains when to use this tool in a review sequence, though it does not explicitly state when not to use it or name direct alternatives.

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

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

With no annotations, the description carries the full burden. It discloses what it inspects, notes that gaps and disabled tracks may be intentional (avoiding misinterpretation), and states it does not inspect Fairlight automation. It implies read-only behavior via 'inspect' but does not explicitly say so, which is a minor gap.

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

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

Three sentences with no fluff: main purpose first, then optional comparison, then caveats. Every sentence earns its place and the structure is easily scannable.

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

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

The tool has an output schema, so return values are covered. The description addresses the main inspection areas, the optional comparison, and important caveats (intentional gaps, no Fairlight automation). It is sufficiently complete for an agent to decide when to call it, though it could mention any prerequisites like an open project.

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. It does by explaining that the optional expected_width/expected_height/expected_frame_rate parameters are for comparing timeline resolution/rate against delivery requirements. It doesn't detail each parameter individually, but their names and the comparison context are sufficient.

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 ('Inspect') and resource ('active-timeline') with clear targets: missing sources, gaps, disabled/locked tracks and clips. It distinguishes itself from siblings like timeline_overview or timeline_audio, and the optional delivery-requirement comparison further scopes its purpose.

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

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

It provides clear context: use this to inspect timeline health issues, optionally compare against delivery requirements, and it warns that gaps and disabled tracks can be intentional. It explicitly excludes Fairlight automation, but does not name alternative tools for that need, so guidance is strong but not fully explicit.

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

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

With no annotations, the description carries the full burden. The verb 'Return' reasonably implies a read-only, non-destructive operation, and listing returned fields adds transparency. However, it does not disclose whether the project must be open, whether empty states are possible, or any other operational behavior, leaving some ambiguity.

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 concise sentence with the key output fields up front. It loses a point for the slightly awkward repetition of 'timeline' and 'timeline count,' which could confuse an agent reading quickly.

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

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

Given the tool is simple, has no parameters, and an output schema exists, the description plus schema is nearly sufficient. The missing usage guidance and the timeline phrasing ambiguity keep it from being fully complete, but there is no major missing information for actually invoking the tool.

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

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

The tool has zero parameters und schema coverage is 100%, so parameter semantics are essentially not applicable. The description adds value by clarifying what information is returned, which is the closest analog to parameter meaning for a no-argument query.

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

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

The description uses a specific verb ('Return') and names the resource ('current project') plus a concrete list of fields. It is clear what the tool does, though the term 'timeline' alongside 'timeline count' is slightly ambiguous, and it does not explicitly differentiate itself from sibling tools like timeline_overview or resolve_status.

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

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

There is no guidance about when to use this tool versus alternatives. Given siblings like timeline_overview, list_timelines, and project_health, an agent would benefit from knowing that project_info is the broad overview of the current project and that timeline-specific details belong elsewhere. No exclusions or alternative suggestions are provided.

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

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

With no annotations, the description carries the burden of revealing behavior. It does disclose the explicit user approval requirement, which is a key behavioral trait. However, it leaves out what 'add a render job' concretely entails — e.g., whether the job is queued, how it interacts with start/user_approved, and what happens if approval is falsified.

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

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

Two sentences with zero filler, each earning its place. The primary action is front-loaded and the critical constraint (approval) is placed immediately after, making the core behavior easy to scan.

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

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

Given five parameters and no annotations, the description is too thin to be complete. It does not explain param roles, side effects of starting the render, or the expected flow, leaving an agent reliant on guesses about parameter interactions.

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 only implicitly references the user_approved parameter via the approval requirement. The other parameters (name, start, preset, output_dir) are left without added semantic meaning, so the description does not compensate for the low schema coverage.

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

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

The description clearly states a specific action ('Add a render job') with a specific resource ('render job') and scope ('current timeline'). It doesn't explicitly distinguish itself from sibling tools like preview_timeline, but the verb+resource combination makes the core purpose clear even without direct comparison.

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

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

No guidance is given on when to use this tool versus alternatives like preview_timeline or list_render_presets. The approval requirement is a constraint, but it does not help the agent decide between this and other timeline-relevant 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 must carry behavioral disclosure. 'Check' implies a read-only operation and the listed status items clarify what is inspected, but it does not disclose failure behavior, connection-state implications, or whether any state is touched. It is adequate but not rich.

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

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

The description is one tight sentence, with the core action and what is checked front-loaded, followed by the vital ordering instruction. Every element earns its place and no filler is present.

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 status tool with an output schema, the description supplies the necessary purpose and sequence. It does not need to explain return values because the output schema covers them, and nothing required to call the tool correctly is missing.

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

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

The input schema has zero parameters, so there is nothing for the description to annotate beyond the schema. Schema coverage is complete by construction, and the baseline for zero-parameter tools is 4.

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

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

The description uses a specific verb ('Check') and identifies a clear resource: the bridge connection state, plus Resolve version, open project, and current timeline. It clearly conveys this is a status/entry-point tool, but it does not explicitly name sibling tools or state how it differs from bridge_capabilities or project_info, so it earns a 4 rather than 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 instruction 'Always call this first' gives an explicit, unambiguous when-to-use rule and establishes sequencing relative to other tools. It does not, however, provide exclusions or name alternatives for cases where a more specific status tool would be preferred.

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

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

With no annotations, the description carries the behavioral disclosure burden. It discloses non-destructiveness ('never deletes clips'), scope of analysis ('starts at the clip's in-point'), and exclusions ('excludes Fairlight processing'). This is meaningful beyond the raw schema.

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

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

The description is compact and front-loaded: purpose and safety first, then analysis scope, then workflow. Each sentence adds value, though the second and third sentences could be combined without loss.

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 workflow integration with apply_silence_cuts is helpful, and an output schema exists, but the complete absence of parameter semantics leaves a major gap. The description does not state how to identify the target clip or what the threshold/duration parameters control, making the tool incomplete for autonomous 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?

Schema description coverage is 0%, so the description must compensate for the five parameters. It does not explain item_id, track_index, max_duration_seconds, min_silence_duration, or silence_threshold_db, nor does it map 'a clip' to any parameter. An agent cannot confidently set these parameters from the description alone.

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

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

The description clearly states the tool's action: analyze source audio for a clip and place yellow review markers. It also distinguishes itself from apply_silence_cuts by explicitly framing this as the review step before cuts are applied, and the 'never deletes clips' clause prevents confusion with destructive editing tools.

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

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

The description gives a clear workflow: audit the markers, then pass accepted marker IDs to apply_silence_cuts. This tells an agent when to use the tool and what to do with its output. It does not explicitly list when not to use it, but the workflow context is strong enough.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates the action without explaining side effects such as overwriting the existing project file, whether the operation blocks, or what happens if the project has unsaved changes. Some of this is implied by 'save,' but the description adds little beyond the tool name.

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 states the action and target with no filler or redundant elaboration. 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 tool with an output schema, the description is nearly complete: an agent knows exactly what action to perform. The only gap is the lack of behavioral detail around persistence side effects, but given the simplicity of the operation this is a minor omission.

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

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

The tool has zero parameters, so there is nothing for the description to explain. Per the baseline for zero-parameter tools, this dimension is well handled by the empty schema.

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

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

The description uses a specific verb ('Save') and a specific resource ('the current Resolve project'). It is unambiguous and distinct from every sibling tool, none of which persist the project.

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

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

The phrase 'current Resolve project' makes the context clear: this saves the already-open project with no arguments. It does not explicitly list exclusions or alternatives, but no sibling offers an equivalent save operation, so the usage context is sufficient.

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

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

With no annotations provided, the description carries the full burden. It discloses an important behavior (empty string clears the color), which is helpful. However, it does not mention side effects, permissions, reversibility, or error behavior, leaving gaps in transparency.

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

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

The description is a single, front-loaded sentence that wastes no words. It includes the core action and a critical edge-case behavior, making it highly efficient and readable.

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?

Although an output schema exists, the description lacks usage context (when to use vs alternatives), does not explain the item_id parameter, and provides no color format details. For a mutation tool with zero annotations, this is incomplete for an agent to invoke 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 0%, so the description must compensate. It adds meaning to the color parameter by explaining that an empty string clears the color. It does not explain item_id or valid color formats, but item_id is relatively self-explanatory from its schema title, so the partial compensation earns a moderate score.

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 'Set a standard Resolve clip color, or pass an empty string to clear it' clearly identifies the specific action (setting a clip color), the resource (Resolve clip), and the key behavior (empty string clears). It distinguishes this from sibling tools like set_clip_grade or set_clip_property by calling out the 'standard Resolve clip color' scope.

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

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

No guidance is given about when to use this tool versus alternatives such as set_clip_property or set_clip_grade, nor are exclusions or prerequisites mentioned. The intended usage is only implied by the name and 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly identifies the mutation (enable/disable) and the non-destructive guarantee, but it does not disclose side effects, idempotency, permissions, or response behavior. The output schema may document return values, but side effects remain implicit.

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 purpose or differentiation, making it efficient and easy to parse.

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

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

For a simple two-parameter toggle with an output schema, the description covers the core operation and non-destructive intent. However, with no annotations and no usage guidance or behavioral details, an agent has to infer edge cases and side effects. It is minimally adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It maps both parameters: 'one timeline item' corresponds to item_id and 'enable or disable' corresponds to the enabled boolean. This adds semantic meaning beyond the bare schema titles, though it lacks detail about value semantics or format.

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 pair ('enable or disable') and a clear resource ('one timeline item'). The qualifier 'without deleting it' distinguishes it from destructive sibling tools like delete_clips. This is unambiguous and immediately actionable.

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 'without deleting it' provides clear context that this tool toggles an item's enabled state while preserving it, rather than removing it. It does not explicitly name sibling alternatives, but the intended use case is clear and the exclusion of deletion is 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 zero annotations, the description carries the full burden, but it only restates the operation without disclosing side effects: whether grading replaces or stacks on an existing grade, whether reset clears other parameters, or whether this is destructive/reversible. The presence of a reset parameter hints at behavior, but the description never explains it. Mutations with no behavioral context are 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?

Two tight sentences: the first delivers verb + resource + parameter mapping, the second adds a practical usage tip. No filler, no repetition of schema defaults, and the key scoping information is front-loaded.

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

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

The output schema covers return values, and the description handles the CDL parameters well. But for a 7-parameter mutation tool, the unexplained reset and node_index semantics, plus the ambiguity about whether the grade overwrites prior grading, leave noticeable gaps an agent must guess about before invoking.

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%, so the description must compensate, and it does add real value by mapping the CDL aliases (slope/gain, offset/lift, power/gamma) to parameters and explaining the saturation=0.0 black & white trick. However, two parameters—reset and node_index—are left entirely unexplained, and the '1.0 1.0 1.0' triple-string format is not described, so compensation is only partial.

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

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

The description uses a specific verb ('Apply') on a clear resource ('clip') and names the exact grading domain (ASC-CDL with saturation, slope/gain, offset/lift, power/gamma). It is clearly distinct from siblings like get_clip_grade (getter) and keyframe_clip_saturation (animation), though it does not explicitly name or exclude any 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 guidance is given about when to use this tool versus alternatives such as set_clip_color, animate_color_fx, or get_clip_grade. The 'saturation=0.0 for black & white' tip is a usage nuance, not a routing rule. An agent must infer the tool's place among 40+ siblings 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 provided, the description carries the full burden of behavioral disclosure. It reveals that the operation is a direct mutation ('set...directly') but says nothing about required permissions, side effects, validation failure, whether existing values are overwritten, or how invalid or unsupported property names are handled.

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

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

Two short sentences with no filler. The core action is front-loaded, and the sibling preference is stated immediately after. 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 an arbitrary low-level property setter with no parameter descriptions and no annotation context, the description is too thin: it lacks examples, a pointer to where property names are documented, value-type guidance, and error behavior. The output schema helps with return values, but the input semantics remain under-specified.

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

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

Schema description coverage is 0%, so the description must compensate, but it only clarifies that property_name refers to a documented timeline item property. It does not explain the expected shape or type of value, how item_id should be obtained, or any constraints on property names.

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

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

The description clearly identifies the action ('set'), the resource ('Resolve timeline item property'), and the scope ('any documented'), and it names the main sibling alternative in the second sentence. An agent can distinguish this low-level setter from focused tools like set_clip_transform, set_clip_enabled, or set_clip_grade.

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 instruction 'Prefer set_clip_transform for common changes' gives explicit routing guidance for a key alternative, implying this tool is for less common or direct property writes. It does not enumerate all sibling exclusions, but for a generic low-level setter this is adequate context.

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

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

With no annotations, the description carries the behavioral burden. It adds useful context: units for pan/tilt, the meaning of zoom = 1.0, opacity range, composite_mode names, scaling values, and that this is a static transform. However, it does not state whether unspecified parameters are left unchanged or reset to defaults, and it omits side effects or prerequisites—important for a 25-parameter setter.

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

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

The description is dense but every sentence earns its place: action, id sourcing, unit semantics, ranges, valid values, and the static-vs-animated caveat. It is front-loaded with the core purpose and organized so an agent can scan it quickly despite the large parameter surface.

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 25-parameter tool with no annotations, this is nearly complete: it explains the required id, how to use playhead, parameter units and ranges, valid mode names, and the key alternative tool. It still lacks semantics for crop/anchor/rotation parameters and whether unspecified values are preserved, which prevents a 5.

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%, so the description must compensate, and it does for many parameters: pan vs pan_percent, tilt vs tilt_percent, zoom vs zoom_x/zoom_y, opacity range, composite_mode names, scaling modes, and the Resolve mode-name params. Some parameters remain undefined (anchor_x/y, crop_*, rotation, flip_x/y, track_index, dynamic_zoom_ease), so it is not a perfect 5.

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

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

The description opens with a specific verb and resource: 'Position, scale, rotate, fade, crop, or blend one timeline item.' It distinguishes itself from sibling tools explicitly by noting this sets a static transform and directing animated zoom to animate_zoom. An agent can tell this apart from get_clip_transform, set_clip_property, and animate_zoom without opening their schemas.

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

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

It gives concrete guidance: use an id from timeline_overview or pass item_id='playhead' to avoid a lookup, and for animated scale use animate_zoom instead. It does not discuss when to prefer set_clip_property or get_clip_transform, but the main competing alternative for transform behavior is clearly called out.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the action of moving the playhead but does not mention prerequisites (e.g., an open timeline), behavior on invalid timecode, or whether the operation has side effects beyond cursor movement. The mutation-like nature is implied but 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?

The description is two short sentences with no filler. The primary action is front-loaded, and the format clarification is directly relevant to invoking the tool. 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 simple one-parameter tool, the description conveys the core action and input format. Yet it omits prerequisites like an open timeline, error handling for invalid timecodes, and any expected return or side effects. The output schema may cover return values, but the description itself remains minimally 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 schema provides zero description for the lone timecode parameter, so the description must compensate. It does specify the expected format ('HH:MM:SS:FF') and ties it to the timeline frame rate, adding needed meaning. However, it stops short of examples or details on frame-rate interpretation, leaving some ambiguity.

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

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

The description clearly identifies the action ('Move') and the resource ('current timeline playhead'), which is specific and distinguishable from sibling tools. However, it does not explicitly differentiate itself from alternatives like timeline_frame or preview_timeline, so it misses the highest tier of clarity.

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

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

The description provides no guidance on when to use this tool versus other timeline navigation tools. The only usage hint is the timecode format, which addresses parameter formatting rather than tool selection. No exclusions or alternative conditions 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It indicates a mutating rename action but does not state whether the track must already exist, whether the operation is reversible, or what happens on invalid input. This is a meaningful transparency gap for a write 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?

The description is a single front-loaded sentence with a clarifying example and no wasted words. It communicates the core purpose efficiently.

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 relatively simple and an output schema exists, so return-value details are not required. Still, the description omits track_type semantics and any error or prerequisite behavior, leaving gaps an agent must guess about.

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 example maps track_index to 'V2' and name to 'Overlays', giving real-world meaning beyond the bare schema. However, track_type is left entirely unexplained, and with 0% schema description coverage the parameter semantics are only partially compensated.

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 ('Rename one track') and gives a concrete example ('labelling V2 as Overlays'), making the intent unambiguous. It does not explicitly differentiate from sibling track operations like add_track, but the rename operation is clearly distinct.

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 example implies this is used when an existing track needs a new label, but there is no explicit when-to-use guidance, prerequisites, or mention of alternatives. Usage context is present but 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 fully shoulders the behavioral transparency burden. It discloses what is preserved (static transforms, enabled state, color, grade layer), what is rejected (Fusion, mixed rates), what is not guaranteed (audio links/fades/metadata), and the failure mode (opens checkpoint, reports partial timeline). This is exemplary transparency for an operation with 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 slightly longer than minimal, but every sentence contributes distinct information: the operation, preservation guarantees, rejection cases, failure recovery, and usage cautions. It is well-structured, starting with the core purpose before diving into caveats. There is no redundancy, so the length is justified.

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

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

Given the output schema exists (so return format is covered), the description provides essential context: prerequisites (checkpoint), constraints (normal-speed only, rejection of Fusion/mixed rates), side effects (preservation and non-guarantees), failure handling, and agent guidance (prefer unique IDs, verify results). This covers all critical aspects for an agent to invoke the split correctly.

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

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

Schema description coverage is 0%, so the description must clarify parameter meaning. It clarifies 'frame' and 'timecode' as an absolute split point, and 'item_id' is implied by the advice to use unique IDs from timeline_overview. However, 'track_index' is not addressed, and default values are left to the schema. The description adds some value but does not fully compensate for the missing schema descriptions.

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

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

The description clearly specifies the operation: splitting a clip at an absolute frame/timecode, with the prerequisite of a timeline checkpoint. It distinguishes this action from sibling tools like delete_clips or set_clip_transform by focusing on the split operation. The mention of 'normal-speed' and the specific preservation details further clarifies the precise functionality.

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

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

The description gives strong usage constraints: it applies to normal-speed clips, rejects Fusion compositions and mixed rates, and warns about audio/metadata limitations. It does not explicitly name alternative tools for other cases, but the conditions are clear enough to guide agent selection. The advice to 'prefer unique IDs from timeline_overview' is also a usage directive.

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

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

With no annotations, the description carries full behavioral burden and does so richly. It discloses exclusions (Fairlight gain, fades, mute, timeline mix), coordinate semantics (cut end frames exclusive, timeline_* absolute), retiming rejection rather than guessing, decode cap, and external tool requirements. These details go well beyond what the input schema provides.

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

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

The description is dense but well-organized: main purpose first, then actions, defaults, coordinate semantics, retiming policy, and dependencies. Every sentence adds useful information with no filler or repetition.

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

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

Given the tool's complexity (9 parameters, no annotations, no schema descriptions), the description covers many critical aspects: actions, defaults, coordinate conventions, dependencies, and retiming behavior. However, it omits semantics for several parameters and does not explain action-specific outputs or prerequisites beyond the ffmpeg/afconvert note. The presence of an output schema helps, but parameter-level gaps remain.

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. It does clarify 'action' values, whole_clip, and max_duration_seconds, but it leaves item_id, track_index, threshold_db, lead_offset_ms, min_silence_duration, and silence_threshold_db without explanation. Parameter names hint at meaning, but the description does not bridge the gap for a complex 9-parameter 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?

The description opens with a specific verb and resource: 'Analyze selected source PCM', and clarifies what is excluded (Fairlight gain, fades, mute, timeline mix). It enumerates distinct actions (analyze, silence_cuts, energy_envelope, export_slice, onsets, vad_clusters), which makes the tool's purpose concrete and separates it from generic timeline or render tools.

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

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

The description provides clear operational context: default range from playhead to clip end, whole_clip behavior, decode cap, and the ffmpeg/afconvert dependency. It does not explicitly name alternatives or when-not-to-use conditions, but the action list and source-PCM scope give enough context for an agent to select it over sibling tools like review_silence or apply_silence_cuts.

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

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

With no annotations, the description carries the full behavioral burden, and it does well: it discloses the auto fallback chain, that source fallback excludes timeline transforms, grades, Fusion and overlays, and that mode='composite' fails explicitly when a true still is unavailable. These non-obvious behaviors are exactly what an agent needs to interpret the returned image correctly.

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

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

The description is compact and front-loaded with the core purpose, followed by three sentences of high-signal fallback and failure behavior. Every sentence earns its place with no repetition 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?

The mode behavior and fallback limitations are covered well, and an output schema exists so return format need not be described. However, with five optional parameters and no schema descriptions, the description leaves open important invocation details: the expected timecode format, whether frame and timecode are mutually exclusive, and what happens when neither is supplied.

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. It adds meaningful semantics for mode ('auto' vs 'composite') and clarifies that frame/timecode refer to absolute positions. However, it does not explain format, max_width, or how frame and timecode interact when both or neither are provided.

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

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

The description clearly states the tool returns 'a native MCP image' for an 'absolute timeline frame or timecode', which is a specific verb and resource. It does not explicitly differentiate from siblings like preview_timeline, but the frame/timecode targeting and 'native MCP image' output make the purpose reasonably distinct.

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 usage: request a still for a specific absolute timeline frame or timecode, with 'auto' mode attempting composite first. However, it provides no guidance on when to prefer this over related siblings such as preview_timeline or set_playhead, and no explicit exclusions or alternative routing.

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

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

With no annotations, the description carries the full burden. 'Inspect' implies a read-only operation, and 'stable unique clip IDs' adds useful behavioral context about ID persistence across edits. However, it does not disclose operational caveats such as how max_items affects results or whether output is truncated.

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

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

The description is a single sentence with no wasted words. It front-loads the inspected content and ends with the recommended call timing, making it easy to parse quickly.

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 simple one-parameter tool with an output schema available, so return values do not need to be described in detail. The description states what is inspected and when to call it, which is sufficient for an agent to select and invoke it correctly.

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

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

Schema description coverage is 0%, and the description never mentions the sole parameter max_items. The schema provides type and default, but the description adds no meaning about what max_items limits or how it affects the returned overview.

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

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

The description uses the specific verb 'Inspect' and enumerates concrete resources: stable unique clip IDs, positional labels, tracks, frame ranges, and markers. This clearly distinguishes it from sibling tools like timeline_frame or timeline_audio, though it does not explicitly name a sibling alternative.

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

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

'Call before and after edits' gives a clear temporal usage context: this tool is meant for capturing timeline state for comparison. It does not state exclusions or name alternative tools, so it stops short of the top score.

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