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

No annotations are provided, so the description carries the full burden for a mutation tool. It does not disclose whether the clip is appended or inserted, how track_index collisions are handled, whether existing audio is affected, or any permission/overwrite behavior.

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

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

A single front-loaded sentence with the action first and parenthetical examples that earn their place. No filler.

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

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

For a 7-parameter mutation tool with no annotations and 0% schema coverage, the description is far too thin; the only relief is that an output schema exists so return values need not be explained. The parameter surface is effectively undocumented.

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

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

Schema description coverage is 0% across 7 parameters (volume, start_ms, duration_ms, track_index, source_start_ms, audio_path, draft_name), and the description adds no meaning for any of them. An agent gets no guidance on units, defaults, or the distinction between start_ms and source_start_ms.

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

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

The description gives a specific verb ('Add'), resource ('audio clip'), and destination ('to the CapCut draft'), plus concrete examples (voiceover, background music, SFX). It does not, however, distinguish itself from the overlapping sibling capcut_add_bg_music_with_ducking, which also handles background music.

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 audio categories hint at use cases, but the description never states when to choose this generic add over siblings like capcut_add_bg_music_with_ducking or capcut_improve_audio. No prerequisites or exclusions are given.

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

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

No annotations provided, so the description carries the full behavioral burden. It explains the ducking concept but omits whether this mutates the draft, requires a rendered timeline, affects existing tracks, or what audio processing happens. For a mutation tool with zero annotation coverage, this is a significant gap.

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

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

Front-loaded with the core action, then a compact bulleted list of key params. Efficient overall, though the bullets duplicate schema defaults rather than adding new information.

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

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

An output schema exists so return values need not be described, and the ducking concept is explained. However, with 7 params at 0% coverage and no annotations, the description leaves several parameters and the mutation semantics unexplained, which is thin for this complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It documents three of seven params (speech_intervals_json with a format example, duck_volume, normal_volume with defaults), which is genuinely useful, but leaves draft_name, music_path, start_ms, and track_index 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?

States a specific verb (add), resource (background music), and a distinctive mechanism (automatic volume ducking under speech). It clearly distinguishes from sibling capcut_add_audio_clip by naming the ducking behavior, though it doesn't explicitly name the alternative.

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

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

The description implies usage (you need speech intervals to duck under) but never states when to use this vs capcut_add_audio_clip or capcut_improve_audio. No prerequisites or exclusions are given, leaving usage 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?

No annotations are provided, so the description carries the full behavioral burden. It says 'add' but doesn't disclose whether captions append or overwrite, whether a render is required afterward, or what the 'preset' styling actually changes – only the captions_json shape is given.

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 lines, front-loaded with purpose then the required data format. Nothing is wasted, though the brevity contributes to the under-specification rather than being purely efficient.

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 explained, but for a mutation tool with zero annotations the description should say more about side effects, sibling routing, and the undocumented preset/draft_name parameters to be callable with confidence.

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 all three parameters. It usefully documents the captions_json format, but leaves draft_name and especially the 'preset' parameter (default 'tiktok_bold') with no explanation of accepted values or effect.

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

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

The description states a specific verb (Add), resource (styled captions) and target (CapCut timeline), so the agent knows the operation precisely. However it gives no differentiation from the sibling capcut_add_karaoke_captions, which is a plausible conflicting choice.

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

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

There is no explicit when-to-use or when-not-to-use guidance. The presence of capcut_add_karaoke_captions as a close sibling makes this omission notable, since nothing tells the agent which caption tool to pick.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It discloses placement ('top center above the avatar'), but says nothing about permissions, whether existing badges are replaced, how start_ms is anchored, duration limits, or what the operation returns — significant gaps for a mutation tool.

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

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

Very short and front-loaded: the core action and placement come first, followed by a compact style enumeration. The bullet-style formatting is slightly informal but wastes no words.

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

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

An output schema exists so return values need not be described, but with zero schema description coverage, no annotations, and 5 parameters, the description should explain far more (timing semantics, required draft context, interaction with existing overlays). It is not complete enough for reliable invocation.

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

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

Schema description coverage is 0% across 5 parameters, so the description is the only source of parameter meaning. It valuably supplies the otherwise-absent enum values for 'style' (red_badge, yellow_pill, clean_dark), but leaves draft_name, headline_text, start_ms, and duration_ms completely 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?

States a specific verb and resource ('Add a high-contrast headline banner') plus concrete examples and exact placement ('top center above the avatar'), which is enough to distinguish it from siblings like capcut_add_captions or capcut_add_proof_overlay. It does not explicitly name or contrast those siblings, so it falls short of a 5.

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

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

There is no when-to-use guidance, no preconditions (e.g. that a draft must already exist), and no mention of alternatives such as overlays or captions for similar on-screen text needs. Usage must be inferred entirely from the name and the 'hook' framing.

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

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

No annotations are provided, so the description carries the full behavioral burden. It conveys the visual effect and the highlight colors, but says nothing about whether it replaces existing captions, what permissions/draft state are required, or how it behaves with the existing timeline for what is clearly a mutating tool.

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

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

Compact and front-loaded: one sentence on the effect followed by a single-line format example. No filler, though the schema-format line could be tighter.

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 explained, and the key timestamp format is given. However, the absence of annotations plus undocumented draft_name/words_per_chunk and no when-to-use routing leaves meaningful gaps for a mutating, multi-parameter 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 coverage is 0%, so the description must compensate. It does document the critical word_timestamps_json with a concrete example and explains the two supported highlight colors, but leaves draft_name and words_per_chunk completely undocumented, so it only partially covers the four parameters.

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

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

States a specific verb (Add) and resource (karaoke captions) and describes the distinguishing visual behavior: the active spoken word lights up in a highlight color. This implicitly separates it from the sibling capcut_add_captions, though it never names that sibling explicitly.

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

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

There is no explicit when-to-use guidance and no comparison to the obvious alternative capcut_add_captions or the other overlay/badge tools. The usage is only inferable from the stylistic description ('viral Hormozi-style'), which leaves the agent guessing when this is preferred over plain captions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose that this is a mutation tool, what draft state is required, how asset_path or timing interact with the draft, whether the operation is reversible, or any permission or rate-limit considerations. The position and scale details add some useful behavior but leave major gaps.

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

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

The description is short, front-loaded with the core purpose, and uses bullets for parameter-specific details. Every sentence and bullet earns its place, with no redundant wording.

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

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

Although an output schema exists and return values need not be explained, the description is incomplete for a 6-parameter mutation tool with no annotations. It omits required-parameter semantics, usage conditions, and behavioral details, leaving an agent with substantial gaps.

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

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

Schema description coverage is 0%, and the description only explains position values and scale relative to a 1080x1920 canvas. It does not explain the required parameters draft_name, asset_path, start_ms, or duration_ms, which are central to correct invocation.

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

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

The description states a specific action ('Add ... overlay') and resource ('proof overlay'), with concrete examples such as an Amazon review screenshot, PubMed study proof, or TikTok comment bubble. This clearly differentiates it from sibling tools like caption, hook-badge, and punch-zoom 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?

It gives no explicit guidance on when to use this tool versus alternatives such as capcut_add_hook_badge or capcut_add_captions. The examples imply a social-proof use case but do not state conditions, exclusions, or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the alternating-zoom mechanic, which is genuinely useful, but says nothing about whether existing zooms/keyframes are overwritten, permission or auth needs, or reversibility for what is clearly a mutation. Coverage is partial rather than misleading.

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 a parenthetical that earns its place by defining the mechanic and mapping two parameters. No filler, though the density of the parenthetical slightly burdens readability.

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 described. For a mutation tool with zero annotation coverage and 0% schema description coverage, the definition is only partially complete: it omits the fate of pre-existing zooms and leaves 2 of 4 parameters undocumented.

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

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

Schema description coverage is 0%, so the description must compensate. It effectively explains zoom_scale and interval_s via the parenthetical, which aligns with their defaults (1.15 and 4), but leaves draft_name and segment_id completely undefined. Partial compensation for a 4-param tool.

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

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

States a specific verb (add) and resource (punch zooms), and even defines the effect — alternating between 1.0x and zoom_scale every interval_s — so an agent knows exactly what this produces. It is distinguishable from siblings like capcut_add_proof_overlay or capcut_add_hook_badge by the effect type, though it never names them explicitly.

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

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

Provides context (talking-head clips in short-form ads) and a rationale (retention), which implies when it is appropriate. However, it offers no explicit when-not guidance, no prerequisites, and no alternatives among the many sibling add_* tools, leaving the agent to infer selection.

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

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

With no annotations, the description carries the full burden, and it partially delivers: it explains that smart_cutout activates native AI portrait background removal and that CapCut strips the background on open/export. However, it says nothing about whether the operation mutates/overwrites an existing draft, permission/auth needs, or ordering constraints with other add_* calls.

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?

Front-loads the core action, then uses a tight bulleted list for the two documented parameters. Efficient with no filler, though the bullets could be scannable one-liners rather than multi-line explanations.

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 10-parameter mutation tool with no annotations, the description is thin: it omits most parameters and all mutation side effects. An output schema exists, so return values need not be described, but the input-side gaps leave the agent under-informed about a complex insertion operation.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate, but it explains only 2 (smart_cutout, track_index). Key params like start_ms, duration_ms, source_start_ms, scale, transform_x/transform_y, and even the required draft_name/video_path receive no added meaning.

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

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

States a specific verb+resource: 'Add a video or photo segment to the CapCut timeline.' An agent can tell this inserts visual media into the timeline, distinct from siblings like capcut_add_audio_clip or capcut_add_captions. It stops short of explicitly naming which sibling to prefer for overlays vs primary placement.

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

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

There is no when-to-use guidance, no prerequisites (e.g. whether a draft must exist first), and no alternative routing. The track_index note ('0 for primary track, 1 for overlay/B-roll') hints at a usage decision but is framed as a parameter fact, not as guidance on choosing this tool.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose substantive traits: a specific audio target (-14 LUFS, denoise, EQ), B-roll placement onto 'Track 2 per timestamps', and the side effect of writing into the CapCut Desktop draft folder. It omits error/overwrite behavior for an existing draft name, but adds real 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 numbered pipeline is front-loaded with a clear summary line, and every item is a distinct, non-redundant step. 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?

An output schema exists so return values need not be explained, and the pipeline sequence is well covered. However, with 7 parameters at 0% schema coverage and no annotations, the definition leaves a meaningful gap around argument formats that an agent would need to call 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% across 7 parameters, so the description must compensate. It loosely maps concepts to parameters (voiceover/audio improvement, avatar clip, background removal, B-roll clips, captions) but never explains the expected JSON shape of captions_json or broll_clips_json, the values of improve_audio_mode, or path formats, leaving most parameters undocumented.

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

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

States a specific verb and resource ('One-shot UGC assembly') and then enumerates the five concrete operations it performs (audio improvement, avatar placement, B-roll overlay, caption rendering, draft save). This clearly distinguishes it from atomic siblings like capcut_add_captions or capcut_add_video_clip, since it is the composite orchestrator.

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?

'One-shot' implies the use case is doing everything at once, but the description never explicitly states when to prefer this over chaining the atomic sibling tools, nor any preconditions or exclusions. Usage 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, the description carries the full behavioral burden. It usefully discloses what is preserved (visual cuts, B-roll timing, cutout settings) and what is swapped (voiceover audio, captions), but it omits side effects such as whether the source draft is modified, whether the new draft overwrites anything, and any permission or audio-format prerequisites.

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 begins with the core action and then enumerates what is preserved and swapped. Every clause earns its place by clarifying the operation's scope, with no redundant or filler text.

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

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

The output schema exists, so return values need not be described. However, for a mutation tool with no annotations and 0% parameter coverage, the description leaves important context unstated, including prerequisites, side effects, and the format expectations for the new audio and captions inputs.

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 all four parameters. It maps semantically to the parameters (source draft, new draft, voiceover audio, captions), but it does not explain expected formats, required versus optional status, or the structure of the optional captions JSON, leaving meaningful gaps.

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

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

The description states a specific compound action (clone and revoice) on a specific resource (a finished English draft into a Spanish/localized version), and it distinguishes itself from siblings like capcut_add_captions or capcut_add_audio_clip by preserving existing edits while swapping audio and captions. An agent can identify the tool's core operation 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 usage scenario: localizing a finished English draft by cloning it and replacing voiceover/captions. However, it does not explicitly say when to use this instead of alternatives such as manually creating a draft, adding audio clips, or adding captions separately. The condition is inferable but not stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the draft is created on disk and gives the exact path, but it does not state whether existing drafts are overwritten, what permissions are required, or any other 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?

Two sentences, front-loaded with the core action, followed by a useful storage-location detail. No wasted words 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?

Output schema exists, so return values need not be explained. However, with no annotations and 0% schema description coverage, the description is incomplete for a 4-parameter creation tool: it omits parameter meanings and key behavioral details such as overwrite behavior or CapCut environment requirements.

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

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

Schema description coverage is 0% for 4 parameters. The description only indirectly hints at width/height through 'vertical (9:16) or landscape' but does not explain draft_name, fps, width, or height, so it fails to compensate for the complete lack of schema documentation.

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

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

States a specific verb (Create) and resource (CapCut project draft) plus orientation options (vertical 9:16 or landscape). Clear purpose, but it does not explicitly differentiate itself from sibling tools like capcut_clone_and_revoice or capcut_assemble_ugc_video.

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?

Implies usage by saying it creates a new draft, but gives no explicit when-to-use guidance, prerequisites, or alternatives to use instead. No exclusions or routing to sibling tools 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 full burden and does disclose the processing pipeline, runtime estimates (~1s vs 5-15s), and the return shape. However it says nothing about permissions, whether the input is modified in place, where output lands when output_audio_path is null, or failure behavior.

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

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

The bulleted mode/target_lufs breakdown is front-loaded and each line earns its place. The closing 'Returns JSON string…' sentence is mildly redundant given an output schema exists, but it is short and harmless.

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

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

For a 4-parameter tool with 0% schema description coverage and no annotations, the description covers the tuning knobs but omits the two path parameters and output-file behavior. An agent could call it, but not 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 and it only half does: mode values and target_lufs semantics (-14.0 LUFS standard) are explained, but input_audio_path and especially output_audio_path (default null) are left undefined, so an agent cannot tell where results are written.

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: 'vocal enhancement and loudness mastering for UGC videos,' with concrete DSP details. It does not explicitly differentiate itself from siblings like capcut_clone_and_revoice or capcut_add_bg_music_with_ducking, so it falls short of the top band.

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?

Mode selection is only implied through the tradeoff prose (fast ~1 sec vs neural ~5-15 sec, neural strips room noise/echo), so an agent can infer when to pick each. There is no explicit when-to-use statement, no exclusion, and no named alternative 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?

No annotations are supplied, so the description carries the full burden. It does disclose the read scope (tracks, segments, materials), which signals a non-destructive inspection and is genuinely useful, but it says nothing about whether missing drafts error, whether the read is expensive, or what the returned structure looks like.

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

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

One compact sentence with the action front-loaded and zero filler. It is appropriately sized for a one-parameter read tool, though it could trade a few words for a routing hint.

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 explained, and one required string parameter is a low-complexity interface. Still, with no annotations and no schema descriptions anywhere, the definition leaves the agent to guess at error behavior and sibling disambiguation.

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

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

Schema description coverage is 0% and the single draft_name parameter has no description. The parameter name is largely self-explanatory, but the description does nothing to clarify whether it must be an existing draft, how it is matched, or whether an ID versus a name is acceptable.

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

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

Specific verb (inspect) plus a precise resource enumeration (timeline tracks, segments, materials of a draft), which tells the agent exactly what it gets back. It does not, however, explicitly distinguish itself from the sibling capcut_list_drafts, which an agent could reasonably confuse it with.

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

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

The description gives no when-to-use guidance, no prerequisites, and no named alternative. The agent must infer from the verb alone that this is a read-before-edit step rather than something like capcut_list_drafts.

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 the behavioral load. 'Scan... to verify' implies a non-mutating pass and it usefully discloses a second check (missing media on disk), but it never states whether issues are merely reported or auto-fixed, nor that the call is side-effect-free and safe to repeat.

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?

Compact and front-loaded: the primary purpose leads, and the secondary media-file check is appended without padding. The trailing sentence is slightly tangential to the 'safe zones' framing but still earns its place as an additional validation.

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 explained. However, the platform parameter — which materially changes the collision rules applied — is left undocumented in both schema and description, and it is unclear whether the tool reports or resolves issues.

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

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

Schema description coverage is 0% for both parameters. The mention of 'TikTok or Instagram Reels UI elements' hints that a platform selection exists, but the description never names the 'platform' parameter, its allowed values, or its 'tiktok' default — leaving the agent to infer that this parameter drives which safe-zone rules apply.

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

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

States a specific verb and resource ('Scan the draft to verify...') and names the concrete failure modes it detects (UI element collisions, missing media). It is unmistakably a read-only validation tool, cleanly distinguishable from the mutating siblings like capcut_add_captions and capcut_render_preview_proxy.

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

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

Usage is implied rather than stated: the agent can infer this is a pre-publish/pre-render check, but the description never says when to run it versus alternatives (e.g., capcut_inspect_draft) or that it is a gate before rendering. No explicit when/when-not guidance.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the read scope ("found on this machine", i.e. local filesystem rather than a cloud account), but says nothing about ordering, pagination, or behavior when no drafts exist. Since it is a zero-parameter, non-mutating list operation, the risk of misuse is low, so this is adequate but thin.

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

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

A single tight sentence with the action and scope front-loaded and no filler. Nothing in it is redundant or wasted.

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

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

An output schema exists, so return values need not be described. For a simple zero-arg listing tool against a large sibling set, the description conveys enough to call it correctly, though a one-clause pointer to inspect_draft as the follow-up would make it 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; the 4 baseline for zero-param tools applies. The only semantic contribution is the scope phrase "on this machine".

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

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

The description gives a clear verb ("List") and resource ("CapCut drafts") and scopes it to "this machine", which distinguishes it from related siblings like capcut_create_draft and capcut_inspect_draft. It stops short of explicitly naming those siblings, so an agent still has to infer the boundary from names alone.

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

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

Usage is implied rather than stated: listing drafts is an obvious discovery step before capcut_inspect_draft or editing tools, but the description never says when to prefer this over inspect_draft/create_draft or what to do with the result. No exclusions or prerequisites are offered.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses key traits: the output format (MP4), approximate execution time (~2-4 seconds), use of FFmpeg, and the independence from CapCut. However, it omits whether the tool requires the draft to exist, whether it overwrites existing files at output_mp4_path, or any permission/error conditions.

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

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

Single, front-loaded sentence that conveys purpose, method, speed, and key benefit without any waste. Every phrase 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?

An output schema exists, so return values need not be explained. However, with no annotations and 0% parameter coverage, critical operational details (e.g., required draft_name, output path behavior, resolution limits beyond defaults) are missing. The description is complete enough for basic understanding but lacks the specificity needed for correct invocation.

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

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

Schema description coverage is 0%, so all four parameters (draft_name, output_mp4_path, width, height) lack documentation in both schema and description. The description mentions 'draft spec' and '540x960', which loosely ties to draft_name and defaults for width/height, but does not clarify the required parameters or the output path semantics. The description fails to compensate for the coverage gap.

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

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

States a specific verb (Render) and resource (proxy preview MP4) with distinguishing details: 540x960 resolution, sourced from the draft spec, and 'without launching CapCut.' This clearly separates it from siblings like capcut_assemble_ugc_video or capcut_inspect_draft.

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

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

The description implies usage by explaining the benefit ('view the edit without launching CapCut') and the speed advantage, but does not explicitly state when to use this versus alternatives like full renders or inspect_draft. Usage is inferable rather than guided.

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

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

No annotations are provided, so the description carries the full burden. It does add real behavioral context by explaining what each mode does (smart_portrait's local AI segmentation without a green screen, chroma keying with hex color and intensity), which goes beyond the schema. It omits, however, whether the operation requires the segment to exist, reversibility, or any permission/auth considerations.

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 purpose is front-loaded in a single sentence and the mode options are presented as a compact list with no wasted prose. Structure is efficient, though the indentation is slightly irregular.

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 described. However, for a mutation tool with five parameters at 0% schema coverage and no annotations, the description leaves required parameters and behavioral constraints uncovered, falling short of full completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It documents the three 'mode' values and implies the roles of chroma_color and intensity, but leaves draft_name and segment_id (the two required params) entirely unexplained and never maps 'intensity' or the hex color to their parameter 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 uses a specific verb and resource ('Toggle background removal on an existing video clip') and scopes it to the CapCut draft, which is unambiguous. It does not explicitly contrast itself with any sibling tool, but the function is distinct enough that an agent can identify its role.

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

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

It implies usage ('on an existing video clip' signals the clip must already exist) but gives no explicit when-to-use, when-not-to-use, or alternatives among the matting siblings. The mode list conveys selection semantics without framing them as usage guidance.

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