Arkeonix CapCut MCP
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools target clearly distinct resources (e.g., list_effects vs apply_effect, add_video vs add_text). A few pairs could cause misselection, such as capcut_add_subtitles_batch vs capcut_add_dynamic_captions or capcut_apply_filter vs capcut_set_color_adjustments, but descriptions generally resolve ambiguity.
Naming Consistency4/5Tools consistently use the capcut_ prefix followed by verb_noun patterns like list_, apply_, add_, set_, and auto_. Minor deviations include capcut_raw_patch and capcut_magnific_enhance_broll, but overall the convention is predictable and readable.
Tool Count2/5With 53 tools, the surface is very large and exceeds the comfortable range for agent navigation. While the video-editing domain is broad, many specialized one-off tools (e.g., capcut_add_progress_bar, capcut_generate_chapters) could be consolidated or composed from simpler primitives.
Completeness5/5The tool set covers the full editing lifecycle: reading drafts, adding/removing segments, transforming clips, applying effects and transitions, managing audio, and even advanced AI-driven scene analysis and auto-editing. No major gaps are apparent for working with CapCut draft files.
Average 3.3/5 across 53 of 53 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only says that an audio clip is added to a track; it does not mention that this mutates the draft, whether a new track is created, whether existing audio is replaced, or what happens with the source file. 'At a time' is under-specified and does not clarify timeline behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, which is good for scanning, but it is too terse for a complex mutation tool with 14 parameters. The ambiguous phrase 'at a time' makes the sentence less precise, and important operational details are absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 14 parameters, no annotations, no output schema, and many sibling tools, this description is insufficient. Required parameters are unexplained, there is no side-effect or error context, and no relationship to the draft/timeline is established. An agent would likely need to inspect schemas or guess to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 36%, and the description does not compensate for the gap. It does not explain the required parameters (draft, file, atSec) or the many optional placement and transform parameters. 'At a time' and 'track' loosely map to atSec and trackIndex, but this is too vague to help an agent correctly populate a 14-parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear action verb ('Add') with a specific resource ('audio clip') and target ('a track'), so the core operation is understandable and distinguishable from sibling tools like capcut_add_video or capcut_add_image. However, 'at a time' is ambiguous—it could mean 'one at a time' or 'at a specific timestamp'—and no draft/timeline context is mentioned, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of alternatives, no prerequisites, and no mention of audio-specific edge cases such as supported formats or where the audio file comes from. Usage is only implied by the tool name and the word 'Add,' rather than stated as a decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. 'Remove a segment' only implies mutation and does not disclose destructive effects, whether removal can affect linked segments, whether changes persist automatically, or what the operation returns. This is a meaningful transparency gap for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and free of filler, which is structurally efficient. However, the terseness crosses into under-specification: it communicates the basic action but omits essential context, so conciseness is achieved at the expense of usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive two-parameter tool with no annotations and no output schema, this description is incomplete. It does not describe how the segment is identified, what happens after deletion, whether the change needs saving, or any constraints. The agent is left to infer most of the contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain that 'draft' identifies the editing context or that 'segmentId' is the target segment to remove. The parameter names are somewhat self-explanatory, but the description adds nothing beyond the schema's names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Remove a segment'. It is specific enough to distinguish deletion from adding, moving, trimming, or splitting a segment, though it is essentially a synonym for the tool name and does not define what type of segment is meant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention selecting the segmentId from the timeline, whether the operation is reversible, or how deletion relates to save/discard workflows. The agent must infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure, but it only states that an image is added. It does not explain whether this mutates an in-memory draft, how default track placement works, whether the image becomes a segment, or what side effects occur at the target time. This is minimal disclosure for a mutating editing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, and the core action is front-loaded. However, its brevity is partly a result of omitted context, so while structurally efficient, it does not fully support the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 14-parameter mutation tool with no annotations, no output schema, and low schema coverage. The description does not explain how the image file is provided, how transforms like scale/position/rotation are used, the default behavior for omitted trackIndex, or the save/discard lifecycle. It is not complete enough for confident autonomous invocation with a specific intended result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 14 parameters with only 36% description coverage, so the description needs to compensate for undocumented parameters. It only loosely maps to 'time' (atSec) and 'track' (trackIndex), while parameters like file, posX, posY, scale, speed, volume, opacity, rotation, srcStartSec, and trackRenderIndex receive no added semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('image') and adds placement context ('at a time on a track'), which helps distinguish it from sibling tools like add_video, add_audio, or add_text. It is clear enough to identify the core function, though it does not explicitly mention the draft context or how this differs from adding a sticker or other visual element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of add_video, add_text, add_sticker, or add_track. No prerequisites, exclusions, or alternative routing conditions are provided, so an agent must infer usage from the tool name and resource type alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 only says 'add a new track' and does not explain whether this mutates the draft in memory, requires saving/discarding, creates an empty lane, or has any side effects on existing tracks. The behavior beyond the bare action is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler and no redundancy. It earns its place by identifying the action and allowed types, though it could have been more informative without much additional length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and three undocumented parameters, the one-line description is insufficient. The agent is left without key context: what 'draft' refers to, what 'name' means, how effect/filter tracks behave, and what a successful result looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates very little. It restates the type enum in prose but adds no meaning for 'draft' (the only required parameter) or 'name'. An agent cannot tell what draft refers to or whether name is a label for the new track.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete operation ('Add a new track') and lists the supported track types, so the core action is identifiable. However, it does not distinguish this generic add_track tool from the many sibling add_* tools such as capcut_add_video or capcut_add_audio, nor clarify that this creates an empty track lane rather than adding media content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like capcut_add_video, capcut_add_audio, capcut_add_text, or capcut_add_sticker. The description does not state whether this is a lower-level primitive for creating empty tracks or how it relates to the specialized add/apply siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 implies a mutation (normalization changes existing volumes) and scopes to a track, which is useful, but it never discloses that this modifies the draft, how 'dialogue/voice' segments are identified versus other audio, whether non-voice segments are left untouched, or whether the change is staged pending capcut_save/capcut_discard. These are material unknowns for an agent predicting 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with an active verb and a tight complement ('across all segments on a track') with zero wasted words. It is appropriately structured for readability, but the brevity borders on under-specification: for a 3-parameter mutation tool, one sentence is near the lower bound of adequate size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a draft-edit workflow implied by siblings (capcut_save, capcut_discard), the description is incomplete. It fails to explain when this is preferable to audio-effect/ducking tools, what the tool returns (no output schema exists to fill this in), how voice segments are detected, and the staged-edit behavior. The high-level purpose is clear, but an agent lacks critical operational details needed to invoke it correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (trackIndex and targetVolume documented), leaving the required 'draft' parameter entirely undocumented, and the tool description adds nothing to compensate — it does not mention draft, trackIndex, or how targetVolume multiplier semantics interact with normalization. The description's phrase 'normalize... volume' loosely aligns with targetVolume, but the required parameter's meaning is a genuine gap that neither schema nor description fills.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description has a specific verb ('Normalize'), a clear resource ('dialogue/voice volume across all segments on a track'), and a defined scope. The unique verb makes it distinguishable from audio-related siblings like capcut_set_audio_fade, capcut_apply_audio_effect, and capcut_auto_duck_bgm, though it never explicitly names or contrasts them. Since no sibling performs normalization, an agent can likely select it correctly, but the differentiation is implicit, not stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over its audio alternatives — nothing about when normalization is appropriate versus auto-ducking, fading, or applying audio effects, and no exclusions or preconditions. The closest siblings (capcut_auto_duck_bgm, capcut_set_audio_fade) operate in a similar 'adjust audio levels' space, so the lack of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It indicates that properties are set, but doesn't say whether values replace or merge with existing ones, how invalid values are handled, whether keyframes are affected, or what side effects occur on the segment or draft.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one front-loaded sentence with no filler, naming the action and affected properties directly. It's efficient, though it is so brief that it shifts important clarity responsibilities to other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no annotations, and no output schema, the description is too sparse to give an agent a complete picture. It omits how draft and segmentId are used, what valid ranges look like, and what the tool returns or changes in the draft state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 12 parameters. It loosely groups them into 'transform / opacity / volume / speed / visibility,' but provides no units, ranges, coordinate system details, or notes on parameter interactions. The parameter names are fairly self-explanatory, but the description adds minimal semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') with a clear resource ('a segment') and enumerates the property categories it modifies. This separates it from segment-add/delete tools, though it doesn't explicitly distinguish it from overlapping siblings like capcut_move_segment or capcut_set_speed_curve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There are no exclusions, prerequisites, or conditions stated, so an agent must infer usage solely from the property list, which is insufficient for choosing among many similar segment-editing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 only says 'Apply' and gives preset names; it does not disclose whether this mutates the draft in place, overwrites an existing speed curve, changes clip duration, requires saving, or what happens on invalid input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The preset examples aid readability, though they mostly duplicate the schema enum, so the sentence could arguably be shorter or more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters, no annotations, no output schema, and a relatively specialized operation, the description is under-specified. An agent cannot confidently know what `draft` refers to, how custom curves are represented numerically, or what effects or errors to expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, which is moderate, and the description adds no parameter-specific meaning. It does not clarify the opaque `draft` parameter, nor does it explain the coordinate space for custom array-based curves (e.g., x/y ranges or normalization). The curve preset examples partly duplicate the schema enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Apply'), resource ('dynamic speed ramping/curves'), and target ('video clip'), and the preset examples make the intent unmistakable. It distinguishes itself from most siblings by subject matter, though it does not explicitly name an alternative or contrast it with similar apply-style tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like capcut_apply_animation or capcut_trim_segment. The description implies 'use when you need speed ramping,' but it does not state conditions, exclusions, or prerequisites such as whether the segment must already have a speed curve or whether a draft must be open.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 says 'Align' and does not disclose whether positions are moved destructively, whether audio durations are modified, whether the operation is reversible, or how linked groups are affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. The action and resources are front-loaded, though the brevity leaves important context unaddressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no annotations, and no output schema, the description omits essential invocation details: what draft is, how segments are selected, and how track indices affect behavior. It conveys the core operation but is not sufficient to call the tool correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain 'draft', 'textTrackIndex', or 'videoTrackIndex'. An agent cannot determine what the required draft refers to or how optional track indices scope the alignment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Align') and explicit segment types ('audio, image and subtitle segments'), plus the alignment rule ('by current order, using each audio duration'). This distinguishes it clearly from sibling operations such as move_segment, trim_segment, or set_props, even without naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, what prerequisite state is required, or whether it operates on selected/linked segments or whole tracks. The description implies a use case but does not state it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details on its own. It only says 'apply', without explaining whether the draft is modified, whether an existing effect is replaced, whether saving is required, what the result looks like, or any side effects. This is too thin 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence and avoids redundancy, which is good. However, it is so terse that it omits important usage and behavioral context. It is compact rather than genuinely helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, two operational modes, no annotations, and no output schema, the description needs to explain more than one sentence provides. It does not cover how to identify valid effects, which parameters apply in which mode, or what the tool returns or changes. The definition is incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high at 88%, and the schema already documents most parameters including effect, params, startSec, intensity, segmentId, trackIndex, and durationSec. The description adds little semantic value beyond confirming 'segment' and 'standalone effect layer' modes, so the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Apply a visual effect') and identifies two target modes: a specific segment or a standalone effect layer track. It is understandable and more specific than a tautology, though it does not explicitly distinguish itself from sibling tools like apply_filter or apply_animation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use apply_effect versus related tools such as apply_filter, apply_transition, or apply_animation. It also does not mention prerequisites like listing valid effects via list_effects, or how to choose between segment mode and standalone layer mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 operation adds keyframes, but it does not state whether existing keyframes are preserved or replaced, what "smooth" means in implementation terms, or that the change is part of a draft that may require saving.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler and is front-loaded with the verb and target. Every word earns its place; the parenthetical property list is a useful compact summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating operation with four required parameters, no annotations, and no output schema, the description is too thin. It does not address existing keyframe behavior, value-range expectations, or the save/discard workflow implied by sibling tools, leaving an agent to infer important operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents most parameters well, including the property enum and keyframe item fields such as timeOffsetSec and value. The description only adds a redundant property list and does not explain the undocumented draft parameter, so it falls at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb "Add" with the resource "smooth animation keyframes to a segment" and lists the animatable properties, so the operation is immediately clear. It does not explicitly contrast with siblings such as apply_animation or set_props, though the keyframe terminology mostly differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives like capcut_apply_animation or capcut_set_props, and no exclusions or prerequisites are mentioned. The only implied use case is from the action itself: adding keyframes for animation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden of disclosing behavior. It mentions adding an overlay with animations but does not explain side effects on the draft, track insertion behavior, default animation, or whether changes require saving.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the core action and object efficiently, though the slash phrasing 'title badge / lower-third overlay' is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no annotations, and no output schema, one sentence is insufficient for an agent to call this tool confidently. The description omits prerequisites, expected effect on the timeline, return behavior, and how animations are chosen or applied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 90%, so most parameters are already documented. The description adds light context by labeling the overlay as a speaker name/title badge, which maps to title and subtitle, but it does not meaningfully extend the schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and a concrete resource ('speaker name and title badge / lower-third overlay'), so the tool's purpose is clear. It is distinct enough from generic text tools, though it does not explicitly name or contrast with siblings like capcut_add_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as capcut_add_text or capcut_add_subtitles_batch. Usage must be inferred from the phrase 'lower-third overlay,' which is better than nothing but leaves selection ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden, but it only states that an effect is applied. It does not disclose whether the effect replaces existing effects, whether effects are reversible, what happens on invalid effect names, or what state the draft is left in. This is a meaningful transparency gap for 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It states the operation, target domain, and examples efficiently, earning its place without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, yet the description does not explain expected return behavior, draft handling, or how to discover valid effect names. Given the complexity of the operation and the many sibling tools, this is not enough for an agent to confidently invoke the tool correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents segmentId and audioEffect, and the description adds useful extra examples such as "Telephone" and "Chipmunk". However, the draft parameter is completely undocumented in both schema and description, so the agent must infer its role. The description partially compensates for the 67% schema coverage but does not fully resolve the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: applying a voice filter or audio scene effect to a clip. The examples clarify the intended domain, and the tool name distinguishes it from visual effect tools like capcut_apply_effect. It is clear but does not explicitly contrast itself with sibling audio tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as capcut_apply_effect, capcut_set_audio_fade, or capcut_normalize_audio. It does not state prerequisites, nor does it mention consulting capcut_list_effects for valid effect names. Usage context is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a non-mutating inspection operation and lists what analysis categories it covers, which is useful with no annotations present. However, it does not disclose whether the tool operates on the current unsaved session or a saved draft, whether validation runs live, or what happens on missing/invalid data. The read-only nature is mostly conveyed by the verb 'inspect' rather than explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the main verb front-loaded and a clear list of deliverables. There is no filler or repetition, though the comma-heavy list reads slightly densely and could be structured more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, an undocumented parameter, and several nearby analytical/validation siblings, the description is incomplete. It does not clarify the draft input, return format, whether the operation is read-only, or how it differs from capcut_validate and capcut_read_timeline. An agent could call it, but not with confidence about expected input and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'draft' parameter beyond the schema's name and type. The agent must guess whether 'draft' is an ID, a file path, or a session reference, and no format or example is provided. Because there is only one parameter and its name is reasonably suggestive, it is not a complete failure, but the description adds no real semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Analyze and inspect') and concrete outputs (timeline statistics, B-Roll coverage percentage, cut count, validation health), making it clear this is an analytical/read-only tool. It does not explicitly contrast with sibling tools like capcut_read_timeline or capcut_validate, and 'validation health' may overlap with capcut_validate, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as capcut_read_timeline, capcut_validate, or capcut_analyze_video_understanding. No exclusions, prerequisites, or conditions are stated, leaving the agent to infer the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 says the tool adds subtitles with styling, but doesn't disclose that it mutates the draft, how it interacts with existing text tracks, or whether it overwrites or merges content. This is a meaningful gap for a tool that edits a draft.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler, and the primary action is front-loaded. It earns its place, though its brevity contributes to the lack of behavioral and usage context scored elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter batch edit with no annotations and no output schema, this one-liner is too sparse. It doesn't clarify what 'draft' must refer to, how subtitle timing fields like durSec and endSec interact, or what happens to the draft after the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 88% description coverage, so parameters are mostly self-documenting. The description's mention of 'typography styling, outline strokes, and positions' loosely maps to fontSize, color, strokeWidth, strokeColor, and posY, but adds no deeper semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Bulk add') and resource ('Burmese/English subtitles'), and mentions typography, outline strokes, and positions. It is specific and understandable, though it does not explicitly distinguish itself from sibling tools like add_text or add_dynamic_captions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'Bulk' implies this is for adding multiple subtitles at once, giving some usage context. However, there is no explicit when-to-use guidance, no mention of when not to use it, and no reference to alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It indicates the source and output type, but does not disclose whether this mutates the draft, overwrites existing chapters, requires a saved draft, or returns data. The word 'Generate' hints at producing markers, but side effects are opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or repetition. It states the action, target, and data source efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a simple one-parameter schema, the tool has no output schema and no annotations, so the description must clarify parameter use and return behavior. Both are absent; an agent would not know what to pass as 'draft' or what to expect back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions 'draft', its format, or whether it is an ID, path, or serialized draft. The parameter name gives only a weak clue and the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Generate'), a concrete resource ('structured YouTube / Social Media chapter markers and timestamps'), and a source ('from scene analysis'). It is clearly distinct from the sibling tools, none of which target chapter generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from scene analysis' implies this tool should be used after scene analysis has been performed, but the description gives no explicit when-to-use/when-not-to-use guidance and names no alternatives. Usage must be inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 core move action but does not mention side effects, constraints on trackIndex, behavior with linked segments, overlap handling, or whether changes are staged until a save/discard step.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It immediately states the action and the optional modifier, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with four parameters, no annotations, and no output schema, this one-sentence description is incomplete. An agent still lacks critical calling context: parameter semantics for half the parameters, track-index behavior, return value expectations, and how this fits into the save/discard workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 only loosely clarifies atSec as 'start time' and trackIndex as 'another track', while leaving draft and segmentId entirely unexplained. Units for atSec, default trackIndex behavior, and how to obtain IDs are absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('move') and resource ('segment'), and clearly states the two dimensions of the operation: a new start time and an optional track change. This distinguishes it from sibling segment operations like delete, trim, split, or align.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related tools such as capcut_trim_segment, capcut_align_linked_segments, or capcut_split_segment. No prerequisites, exclusions, or context are provided, so an agent must infer usage solely from the operation name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 states that subtitles are added, but does not mention whether this overwrites existing captions, creates a new track, requires a selected track, or has any side effects on the draft timeline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no wasted words. It front-loads the core action and includes only high-signal stylistic details that help an agent understand the intended visual output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no annotations, and no output schema, a one-sentence description leaves too much unspecified. It lacks guidance on track selection, timing semantics, interaction with existing captions, and when to prefer this tool over capcut_add_subtitles_batch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high at 88%, so the schema already documents most parameters. The description adds stylistic context like pop colors and heavy outline, which loosely maps to highlightColor and strokeColor, but it does not meaningfully explain parameter behavior beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Add modern dynamic word-highlight subtitles'. The 'Alex Hormozi style' and 'pop colors and heavy outline' details make this visually distinct from generic text or subtitle tools. It clearly differentiates itself from siblings like capcut_add_text and capcut_add_subtitles_batch through the word-highlight behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as capcut_add_subtitles_batch or capcut_add_text. The description does not state prerequisites, exclusions, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 one precondition—that the draft must contain a text layer—but does not explain what the operation does to the timeline, whether it mutates the draft, whether it creates a new segment, or whether it has any destructive effects. This is too thin 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: the action is front-loaded and the prerequisite is shared concisely. The pointer to CAPCUT_TEMPLATE_DRAFT is an efficient way to reference external context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, 3 required, no output schema, and no annotations, this description is under-specified. It does not explain coordinate semantics, time units, duration handling, track selection, or how the template draft is actually used. An agent would likely need additional documentation to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, so the description must compensate, but it only clarifies the draft parameter as a text template. No meaning is added for posX, posY, atSec, durSec, fontSize, trackIndex, or text, leaving the agent with mostly self-evident but unverified parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Add a text overlay.' It also adds a key precondition about requiring a text template draft. However, it does not explicitly distinguish this tool from caption, subtitle, or lower-third siblings, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates the tool is only appropriate when a text template draft (a draft with a text layer) is available, referencing CAPCUT_TEMPLATE_DRAFT. This is useful contextual guidance, though it does not explicitly list when not to use it or name alternative tools such as capcut_add_subtitles_batch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral context, but it only states that a mask is applied with certain options. It does not clarify whether an existing mask is replaced, whether the mask applies only to video segments or also images/text, or what side effects occur on the timeline. This is a significant transparency gap 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource, then lists the selectable mask shapes and key effects. There is no redundant or filler content, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is an 11-parameter editing operation with no output schema and no annotations, yet the description provides only a terse one-line summary. It omits critical context such as which segment types are eligible, whether the mask replaces an existing mask, and what the expected result is, so the tool is not fully specified for an agent making a selection decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 91%, so the schema already documents most parameters in detail. The description adds little beyond restating feather and inversion, so the baseline score of 3 is appropriate; the description does not need to compensate for parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as applying a video shape mask and enumerates the supported mask types along with feather and inversion, making the tool's purpose unmistakable. The verb 'Apply' plus the specific resource 'video shape mask' distinguishes it from sibling tools like capcut_apply_effect and capcut_apply_transition without requiring schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use a shape mask versus related operations such as chroma key, effects, or animations, nor any indication of limitations or alternatives. The intended use case is only implied by the tool name and mask-type list, leaving the agent to infer selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 only says 'Apply...', implying in-place mutation, but does not disclose whether the draft is modified immediately, whether persistence requires capcut_save, whether existing layout settings are overwritten, or how scale interacts with corner presets beyond the schema default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundant detail. It communicates the essential action and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with four parameters, no annotations, and no output schema, yet the description only states the action. It omits persistence semantics, side effects, the optional scale caveat, and any comparative guidance against sibling layout-related operations, leaving the agent under-informed for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for layout, scale, and segmentId (75% coverage), so the description does not need to repeat them. However, the description adds no new parameter meaning, and the required 'draft' parameter remains undocumented in both the schema and the description, leaving a small gap that the description does not fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Apply'), a specific resource type ('layout preset'), and a target ('clip'). It clearly distinguishes this from sibling apply_* tools by naming the preset kind as Picture-in-Picture or Split-Screen, leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the many sibling apply_* tools (effect, transition, animation, filter, mask, etc.), nor does it mention prerequisites, ordering, or alternatives. Usage context must be entirely inferred from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 does mention the external Magnific AI API and the timeline insertion with Ken Burns zoom, but it omits important behavior such as whether this modifies the draft destructively, whether an API key is required, what happens on API failure, and whether existing timeline content is affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose and key behavior. Every word earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 11 parameters, no output schema, and no annotations. The description covers only the high-level action and misses critical operational context such as API key requirements, sourceImage vs. prompt modes, track placement defaults, failure behavior, and what the tool returns or changes on the timeline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 91%, so the input schema already explains nearly all parameters. The description adds slight context by mentioning 4K/8K and Ken Burns slow zoom, which loosely maps to scaleFactor and kenBurns, but it does not meaningfully clarify parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—generate or upscale a cinematic 4K/8K B-Roll visual using Magnific AI—and indicates it inserts into the timeline with Ken Burns zoom. This clearly identifies the tool's function and differentiates it from generic add-video/add-image tools, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The implied usage is clear: use this when you need an AI-generated or AI-upscaled B-Roll visual inserted into a CapCut timeline. However, there is no explicit guidance about when to prefer this over siblings like capcut_auto_insert_broll or capcut_add_video, and no stated exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only says values can be changed; it does not disclose what happens to the rendered timeline, whether the draft is mutated immediately, whether changes need save, or whether setting srcStartSec shifts media content. This is a thin behavioral contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one front-loaded sentence with no filler, repetition, or irrelevant context. The key operation and attributes lead immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating 5-parameter tool with no annotations and no output schema, this is thin: no usage guidelines, no prerequisites, no side-effect or save/discard context, and no return-value mention. It is enough to identify the tool but not to call it with confidence in complex timeline scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage the description is the only place parameter meaning is explained. It connects durSec to duration, atSec to start, and srcStartSec to source in-point, and specifies seconds. It does not explicitly map draft/segmentId or clarify mutual constraints between atSec, durSec, and srcStartSec, but it provides substantive semantic help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Change') and resource ('segment') with three distinct editable attributes ('start', 'duration', 'source in-point'), plus units. This separates it from siblings like capcut_move_segment or capcut_split_segment, which target different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No sentence describes when to use this tool instead of capcut_move_segment, capcut_split_segment, or capcut_delete_segment. The only signal is the tool name and the general description, so an agent gets no explicit routing or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of disclosing side effects, but it only states what is placed and not what happens to the draft, whether the operation is reversible, or how it interacts with save/discard. 'Place' implies a mutation but does not describe its scope or consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single, tight sentence with no filler and front-loads the operation and the main placement attributes. It earns its place without redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema plus one-sentence description is minimally adequate for basic invocation, but it leaves gaps around where valid sticker resources come from, what draft state is required, and what the tool returns. Given no annotations and no output schema, these are clear but not fatal omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 90%, so the schema already documents most parameters; the description's 'time, position, scale, and duration' loosely maps to atSec, posX/posY, scale, and durSec but adds no new format or syntax detail. This is the baseline for a schema-rich definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a concrete verb ('Place') and names the resource ('sticker/overlay') and the meaningful placement axes ('time, position, scale, and duration'). This clearly differentiates it from sibling content-add tools like capcut_add_text or capcut_add_audio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to choose this tool over alternatives or for prerequisites such as obtaining a sticker via capcut_list_stickers or ensuring the target draft is loaded. The absence of exclusions or sibling routing leaves the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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, yet it only states the basic operation. It does not mention whether applying an animation overwrites an existing one, how the animation type defaults work, or what happens when 'group' is used.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler. It front-loads the action and then states the applicable targets, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus schema is minimally sufficient for calling the tool, but it lacks usage context such as referencing capcut_list_animations for valid animation names and does not describe return behavior. For a 6-parameter tool with no annotations and no output schema, more contextual detail would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high at 83%, and the schema already documents segmentId, animation, animationType, startSec, and durationSec. The description adds no parameter meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Apply') and resource ('an in/out/loop animation') and explicitly names the target types: video clip, image, or text overlay. This clearly distinguishes it from sibling tools like capcut_apply_effect or capcut_apply_transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as capcut_list_animations, capcut_apply_effect, or capcut_apply_transition. An agent is not told how to discover valid animation names or when animation application is preferred over effects/transitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says a cutout is applied and exposes intensity/shadow. It does not disclose whether the edit is destructive, whether it modifies the draft in place, what segment prerequisites exist, or what happens to the original background.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short front-loaded sentence with no filler; the 'Green Screen / Chroma Key' synonym pair is mildly redundant but does not materially hurt clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, this is too thin: it omits usage boundaries, behavioral consequences, and enough context to pick safely among many sibling apply_* tools without relying on the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% and the schema already explains color, intensity, shadow, and segmentId; the description merely repeats the names intensity and shadow without adding behavioral or range context. Baseline 3 applies since the schema carries the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (Apply) on a specific resource (Green Screen / Chroma Key background cutout) and names the two key controls, so it is clearly distinguishable from sibling apply_* tools such as apply_effect or apply_mask.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by 'Green Screen / Chroma Key background cutout' - an agent can infer this is for removing a solid-color background - but it neither names alternatives nor states when not to use it (e.g., versus apply_mask).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 says 'Apply' but does not state whether this replaces or stacks existing filters, whether a standalone track is created as a new layer, whether the operation is reversible, or what side effects occur on the target segment/track. This is a significant gap 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It immediately states the verb ('Apply'), the resource ('color filter (grade/look)'), and the key target alternatives. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The combination of description and schema is minimally viable for an agent to make a basic call: provide draft and filter, optionally segmentId or track parameters. However, with no annotations and no output schema, the definition omits side effects, return behavior, and the connection to capcut_list_filters for discovering valid filter names. Clear gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (86%), so the schema already documents most parameters. The description adds the 'specific segment or standalone adjustment filter track' distinction, which loosely reinforces the segmentId semantics, but it does not meaningfully compensate for the undocumented 'draft' parameter or add details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Apply a color filter') and clearly identifies the resource type ('color filter (grade/look)'), distinguishing it from effect/transition tools. It also specifies the two invocation modes ('specific segment' or 'standalone adjustment filter track'), giving the agent a precise mental model of what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus siblings such as capcut_list_filters, capcut_apply_effect, or capcut_set_color_adjustments. It explains the two placement modes but does not mention prerequisites like first listing available filters or when a standalone track is preferable to segment application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits, but it only states the operation type. It does not say whether unspecified sliders are left unchanged or reset, whether the segment must already support color adjustments, or what side effects or prerequisites exist. This is a meaningful gap for 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with the action and target front-loaded. It contains no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a fairly simple setter with a well-documented schema, the core call is mostly inferable. However, the description omits important context such as the role of `draft`, behavior when an adjustment parameter is omitted, and prerequisites about the segment type. This leaves some gaps, but it is not severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, and most parameters (segmentId, brightness, contrast, saturation) already have descriptions. The description adds the context that these are manual slider adjustments, but it does not compensate for the undocumented `draft` parameter or clarify parameter interactions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Set') and resource ('manual slider color adjustments ... on a segment'), and enumerates the three adjustments (brightness, contrast, saturation). It clearly communicates what the tool does, though it does not explicitly differentiate it from sibling tools like capcut_set_props or capcut_apply_filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is reasonably implied: apply direct slider-based color adjustments to a segment. However, the description gives no explicit guidance on when to use this instead of filters, effects, or other color-related tools, nor does it mention whether it complements or replaces existing adjustments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It reveals that the tool mutates the timeline by splitting a segment, but it does not mention side effects, whether the operation is destructive to the original segment, whether the draft needs saving, or what happens to segment IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. Every word earns its place and the core action is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and three required parameters, this description is too sparse. It does not explain what a successful split returns, whether the draft is modified immediately, or how the parameters relate to the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and this description only hints that 'atSec' refers to a timeline time. It does not clarify the roles of 'draft' and 'segmentId', nor does it specify units or accepted formats beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Split a segment into two at a timeline time.' It clearly communicates the operation and distinguishes it from related tools like capcut_trim_segment, which adjusts endpoints rather than creating two segments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when a segment needs to be divided at a specific time—but it does not explicitly contrast it with alternatives such as trim, move, or delete, nor does it 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the categories of validation performed, which adds real behavior beyond the tool name. However, with no annotations, it does not explicitly state whether the tool is read-only, whether it can mutate the draft, or what happens when problems are found (returned report vs throw).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single 16-word sentence, front-loaded with the action and followed by a compact enumeration of checks. Every word adds information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description leaves unclear the return value (boolean vs list of issues), the exact meaning of the draft string, and error behavior. Completeness is low for an agent that must decide whether validation passed and how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'draft' as a required string with no description, so the burden falls on the description. It identifies the draft as 'in-session' but does not explain whether the string is a draft ID, serialized draft JSON, or a reference to a session object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('check'), a specific object ('the in-session draft'), and enumerates the exact integrity dimensions checked (overlaps, duplicate ids/render_index, dangling references, missing media). This clearly distinguishes it from editing and inspection siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call validation versus alternatives such as capcut_inspect_edit or capcut_read_timeline, and no mention of whether to run it before save or after edits. The only contextual hint is the parenthetical 'in-session,' which does not define selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the animated fill behavior and the full-duration span, which is useful. However, there are no annotations and the description does not mention side effects on the timeline, whether it creates a new track or modifies an existing one, or what the operation returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that is front-loaded with the core action and animation behavior. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The required 'draft' parameter is not explained, and there is no mention of return values, side effects, or follow-up actions like saving. For a mutation tool with no annotations and no output schema, the description is too sparse to fully guide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (color, position, trackIndex are documented), so the schema carries most of the parameter meaning. The description adds no parameter-specific detail and does not clarify the required 'draft' parameter, which remains undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: adding an animated progress bar that fills from 0% to 100% across the video duration. It identifies a specific resource and behavior, and it is distinct from the sibling add_* tools like add_text or add_lower_third.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives, no exclusions, and no mention of prerequisites like needing a track or draft. The sibling list contains many add_* tools, but the description does not help an agent choose among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 does not state whether the tool modifies the draft, whether it is read-only, or that it invokes external AI APIs (requiring network access or API keys). The word "analyze" implies non-destructive behavior, but this is not explicit, and external dependencies are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and outcome. No wasted words, and it clearly communicates both the extraction and analysis purposes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity (7 parameters, AI providers, frame extraction, no output schema), the description does not explain what the tool returns (e.g., analysis report, frame descriptions, recommended edits), nor does it mention prerequisites or side effects. An agent would need more context to know what to expect from the invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so the schema documents most parameters (model, provider, maxFrames, videoPath, intervalSec). The description adds no detailed parameter semantics beyond what's in the schema, but that is acceptable given the high baseline coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources: "Extract keyframes from video and analyze scene composition, emotion, visual actions, and recommended CapCut edits." This clearly distinguishes it from sibling tools, which are primarily editing/manipulation actions (add, delete, trim, apply effect, etc.), while this is an analysis tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need scene composition, emotion, visual actions, or edit recommendations from a video. However, it does not explicitly state when to use this tool versus alternatives like capcut_find_visual_scenes or capcut_inspect_edit, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavior disclosure. It states the core volume-ducking behavior but does not mention that this modifies the timeline/BGM track, may overwrite existing volume automation, requires a saved draft, or whether the change is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One focused sentence communicates the exact behavior without redundancy or filler. The core action is front-loaded and every part of the sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the parameter schema covers most inputs, the description is too thin given the lack of annotations and output schema. It does not clarify that the operation mutates the draft, requires saving via capcut_save, or what happens to existing manual volume keyframes, so the agent lacks important operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, with baseVolume, duckVolume, bgmTrackIndex, fadeDurationSec, and speechTrackIndex documented. The description itself adds no parameter-specific meaning and leaves the required 'draft' parameter undocumented, but it does not need to repeat the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (automatically duck/lower) on a specific resource (BGM music volume) with clear conditions (during speech, raise during silence). This clearly distinguishes it from sibling audio tools such as capcut_set_audio_fade or capcut_normalize_audio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the description: call it when BGM should be automatically reduced under dialogue. However, it provides no explicit when-not-to-use guidance or comparison to alternatives like capcut_set_audio_fade, leaving the selection logic partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose mutation behavior. 'Place' implies modifying the timeline, but it does not explain side effects like whether the overlay track is created, whether existing B-Roll is replaced, permissions needed, or reversibility. This is a significant gap for a mutation tool without 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main function with no filler. Every element ('B-Roll cutaways', 'overlay track', 'designated timestamps') contributes meaning, making it appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and an undocumented required draft parameter, the description is insufficient. An agent cannot infer prerequisites, side effects, or how to specify the draft target, making it incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (draft lacks a description). The description adds context for insertions (B-Roll cutaways, timestamps) and trackIndex (overlay track), but the draft parameter remains unexplained. It partially compensates for the schema gap but does not fully clarify all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('place') and resource ('B-Roll cutaways on an overlay track at designated timestamps'), making the core function clear. It is distinguishable from siblings like capcut_add_video or capcut_add_image by emphasizing the automated overlay placement, though it does not explicitly name a differentiating sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for placing multiple B-Roll cutaways at specified timestamps, which implies batch/automated use. However, it does not explicitly state when NOT to use it or point to alternatives (e.g., capcut_add_video for single clips), leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 mentions what the tool does on a high level but does not reveal whether the operation is destructive, whether it modifies existing cuts/zooms, how it affects the draft, or what the resulting timeline state 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and it front-loads the core operation before specifying the relevant edit types. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, a richer description is needed. The current text explains the basic action but omits side effects, preconditions, return value, and failure behavior, which is important for a timeline-mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema covers most parameters. The description adds semantic meaning by linking 'cuts' to the action enum and 'punchy zoom pulses' to zoomScale, and 'beat markers' to beatTimestamps. However, it does not clarify the purpose of the 'draft' parameter, which remains undocumented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action verb ('Synchronize'), identifies the resource ('timeline edits'), and clarifies the exact modalities ('cuts or punchy zoom pulses') and the target ('music beat markers'). This clearly differentiates it from sibling tools like align_linked_segments or auto_jumpcut.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when the user wants timeline edits aligned to musical beats. However, it provides no explicit guidance on when not to use it or how it compares to similar automated editing tools such as capcut_auto_jumpcut or capcut_auto_duck_bgm.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 that the edit is session-scoped and only becomes permanent after calling capcut_save, which is a critical operational fact. It does not disclose other behavioral traits such as whether existing clips are replaced, whether validation occurs, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded, and the session-save caveat is the second, equally important fact. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter, no-annotation, no-output-schema mutation tool, this description is too thin. It gives a valuable save instruction but lacks guidance on parameter dependencies, defaults, sibling tool selection, or preconditions, making it insufficient for an agent to invoke the tool correctly in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 36%, so the description needed to compensate for the 14 parameters, but it adds almost nothing. 'video clip' faintly implies the file parameter should be a video file, and 'track' hints at trackIndex, but required parameters like draft are left unexplained and no defaults or unit details are provided beyond the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a precise action ('add a video clip') and a specific resource ('a track'). The word 'video' clearly differentiates this from sibling add_* tools such as capcut_add_image, capcut_add_audio, and capcut_add_text, and 'at a time' signals it is not a batch operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys implied usage context: use this tool to place a single video clip on a track. 'Session edit; call capcut_save to persist' also tells the agent that persistence requires a later capcut_save call. However, it does not explicitly state when not to use it, name alternatives, or mention prerequisites like draft validity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 states it searches a catalog, which weakly implies a read-only lookup, but it does not mention whether data comes from a local cache or network, what the response looks like, whether any project state is touched, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single front-loaded sentence with a clear verb and resource, followed by useful examples in parentheses. Every word contributes, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with fully documented parameters, the description is almost sufficient, but there is no output schema and the description does not explain what a returned entry contains or how results relate to capcut_apply_transition. This leaves a moderate gap in the agent's ability to fully anticipate the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents limit, query, and cachedOnly. The description's examples are catalog entry names rather than parameter explanations, so it adds no meaningful parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Search', and a clear resource, 'CapCut transitions catalog', with example entries like Cross Dissolve. This readily distinguishes it from sibling catalog tools such as capcut_list_effects and capcut_list_filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for finding transitions in the catalog, but it never explicitly says 'use this to look up transitions before calling capcut_apply_transition' or mentions when not to use it. No alternatives or exclusions are stated, so the usage guidance remains only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It reveals key behaviors: writing to disk, backing up .mcpbak, validating, and refusing when CapCut is open unless force is set. This goes well beyond the schema, though it doesn't clarify failure behavior or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the core action and immediately followed by behavioral caveats. Every clause earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action, backup, validation, and the force guardrail, which is adequate for a simple save operation. Clear gaps remain: the meaning of the required 'draft' parameter and expected return or error behavior. Given no annotations or output schema, these gaps matter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 force behavior well: 'Refuses if CapCut is open unless force:true'. However, the required 'draft' parameter is never described, leaving the agent uncertain whether it is an ID, path, or draft name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action and resource: 'Write session edits to disk'. It adds distinguishing details like backing up .mcpbak and validating. However, it doesn't explicitly differentiate from siblings such as capcut_discard or capcut_validate, so it falls just 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.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when session edits should be persisted to disk. It also provides one concrete condition: refuses if CapCut is open unless force:true. But it gives no explicit guidance on when to prefer this tool over alternatives like capcut_discard or capcut_validate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It states the mutation ('Set') but does not mention whether existing fades are replaced, whether changes are reversible, whether the draft must be saved, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes to understanding the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a relatively simple tool and the schema covers most parameters, so the description plus schema is minimally sufficient for an agent to invoke it. Still, without annotations or an output schema, behavioral details and return expectations are left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents fadeInSec, fadeOutSec, and segmentId including defaults and target type. The description adds little beyond 'audio or video clip', and the required `draft` parameter remains undocumented in both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') with a clear resource ('fade-in and fade-out durations') and target ('audio or video clip'). This clearly distinguishes the tool from siblings like capcut_apply_audio_effect, capcut_normalize_audio, or capcut_set_props.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the name and description: use this when the user wants to apply fade durations to a clip. However, there is no explicit guidance about when not to use it or which alternatives might be better for related audio adjustments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Search' reasonably conveys a non-mutating read operation, and the catalog size adds useful context. It does not mention behaviors like cachedOnly semantics or no-query behavior, but the read-only nature is adequately implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact, front-loaded sentence with no filler. Every segment—search action, resource, approximate catalog size, and search axes—adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter catalog search tool, the description plus the fully documented schema is largely sufficient: an agent knows to pass query, category, limit, or cachedOnly. Minor gaps are the lack of a return-format note and ambiguity about behavior when both query and category are omitted, but these are not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds only the keyword/category search mapping, which is already reflected in the query and category parameters. Limit and cachedOnly are already documented in the schema and need no repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and resource ('CapCut visual/character effects catalog'), and adds useful scale context (~1800+ entries). It is distinguishable from siblings like list_transitions, list_filters, and list_stickers, though the phrase 'visual/character effects' undersells the audio_effect enum in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'Search' implies this is for discovering catalog entries rather than applying effects or modifying a timeline. However, the description does not explicitly name sibling alternatives or state when not to use this tool, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility for behavior. It only says 'Change project canvas aspect ratio' and omits side effects on existing media (e.g., cropping, stretching, letterboxing) or whether custom dimensions override preset ratio. This is a significant gap for 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with useful examples and zero filler. The key action is front-loaded, and each clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no output schema, the description is too thin. It fails to explain custom dimension use, relationship between ratio and width/height, and what 'draft' refers to, leaving an agent to infer required parameter combinations. The examples cover preset ratios only.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes ratio, width, and height, covering 75% of params; the description adds value by mapping presets to platforms. However, it doesn't explain the draft parameter or how custom width/height interact with ratio, which an agent needs to construct correct calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource: 'Change project canvas aspect ratio'. The examples ('9:16' for TikTok/Reels, etc.) reinforce the precise scope. This is distinct from sibling tools like capcut_set_canvas_blur, which targets blur.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete use-case context via platform-specific ratio examples, telling an agent when to pick a ratio. It does not name alternative tools or explicitly state exclusions, but the domain is so specific (canvas ratio) that confusion is unlikely. Enough guidance to select the tool over unrelated canvas tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden; it does disclose the essential placement behavior and that it targets the following clip. However, it does not mention side effects such as replacing an existing transition, whether the draft is only modified in memory, or any pruning or validation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficiently front-loaded with the action and target, with a clarifying parenthetical. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple one-operation tool, but with no annotation or output schema it leaves gaps around valid transition sources, behavior on the last segment, and what the operation returns or commits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so most parameters already carry their own descriptions. The tool description adds only a little contextual framing around segmentId and transition, but no detail about the draft parameter or accepted value formats beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Apply a transition') and precisely locates the operation ('after the selected clip segment (transitioning into the following clip)'). This clearly distinguishes it from sibling tools like capcut_apply_effect or capcut_apply_animation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The placement detail implies the tool is used when a transition between two adjacent clips is wanted, but it never states when not to use it or cross-references capcut_list_transitions for valid transition names. No alternative or exclusion is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the destructive consequence ('delete') and mode ('ripple-delete'), which tells the agent the timeline will be altered. However, it does not mention reversibility, in-place draft modification, or side effects beyond the main video track.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the action, with no filler. It conveys purpose, scope, and basis efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive auto-edit tool with no annotations and no output schema, so the description should ideally warn about in-place modification and mention safety workflows such as cloning or discarding the draft. The current text explains the core operation but omits these operational guardrails, leaving a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 3 of 4 parameters. The description adds high-level context by mapping 'speech intervals' to the speechIntervals parameter and 'main video track' to trackIndex, but it adds no detail on draft or paddingSec. This is adequate but does not significantly exceed the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'slice and ripple-delete' with a clear resource ('silence dead space on the main video track') and basis ('based on speech intervals'). It clearly communicates an automated jump-cut operation and is distinguishable from manual tools like capcut_delete_segment or capcut_trim_segment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: automatically remove silence from the main video track when speech intervals are known. It does not explicitly contrast with alternatives or state when not to use, but the 'automatically ... based on speech intervals' condition provides adequate contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral burden. 'Search and retrieve' and 'timestamped scenes' do suggest a non-mutating read operation and hint at the return value, but there is no explicit statement that the draft is not modified, that an understanding map must pre-exist, or how missing-map failures 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-structured sentence front-loads the primary verb and resource, then supplies concrete examples. There is no filler, no redundant restatement of the tool name, and no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two simple parameters and no nested objects, this is a fairly light tool, but there is no output schema, so the description should carry return semantics. It does mention 'timestamped scenes' but omits the prerequisite that the draft's video understanding map must already be built, which is relevant given the sibling capcut_analyze_video_understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the query parameter is already described, but the required draft parameter has no schema description. The tool description adds alternative query examples and frames query as a visual/emotion search, but it does not clarify what draft refers to or how it connects to the video understanding map.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb-resource pair: 'Search and retrieve timestamped scenes from the video understanding map' and gives concrete query examples. This clearly distinguishes it from siblings like capcut_analyze_video_understanding or capcut_semantic_edit, which build or edit understanding rather than retrieve matching scenes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from the video understanding map' implies the tool is meant for querying an already-built map, and the examples clarify the visual/emotion query format. However, it never explicitly says when to use this tool versus capcut_analyze_video_understanding, capcut_semantic_edit, or other scene-related siblings, nor does it state the prerequisite that the map must already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It discloses the catalog size and supported categories, which is useful, but it does not mention that this is a read-only listing operation, describe the return format, or clarify any caching/network behavior implied by the cachedOnly parameter. The description is not misleading, but it leaves behavioral details to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the action and includes meaningful scope details. There is no filler, redundancy, or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for selecting the tool and understanding its domain, but because there is no output schema, it leaves the return shape unspecified. An agent would benefit from knowing what fields are returned (e.g., animation IDs/names) and how results relate to capcut_apply_animation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters and their roles. The description adds only catalog-level context and repeats categories already present in the type enum, so it does not materially enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('CapCut animations catalog'), and clearly scopes the catalog by categories ('in, out, loop, group for video or text'). This distinguishes it from sibling list tools like capcut_list_effects and capcut_list_transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for discovering available animations, likely before applying one with capcut_apply_animation, but it does not explicitly state when to use it versus alternatives or when not to use it. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. The verb 'Search' and the phrase 'available and cached' signal a read-only lookup, but the description does not explain cache semantics, network behavior, pagination, or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, with no redundant wording or filler. It is compact, scannable, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search tool with two optional parameters and no output schema, the description is adequate but not fully complete. It does not state what the response contains (e.g., sticker IDs, names, types) or how results connect to capcut_add_sticker, which matters more because there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both `query` and `limit` are already documented in the input schema. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' and names the resource ('CapCut stickers, emojis, subscribe buttons, and badges'), with a scope qualifier ('available and cached'). This clearly distinguishes it from sibling list/search tools such as capcut_list_effects or capcut_list_filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied by the resource type: an agent would search stickers before using capcut_add_sticker. However, there is no explicit when-to-use, when-not-to-use, or alternative-tool guidance, so the usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 does convey that the tool automatically matches a scene query to an action, implying AI-driven selection rather than a deterministic explicit choice. However, it does not disclose side effects on the draft, whether the change is persisted, or that the semantic matching may produce varying results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the core behavior and action list. It wastes no words, though it is arguably too brief to cover the full complexity of the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and no output schema, a more complete description is needed. It does not explain what the tool returns, whether it modifies the draft immediately, how the matching process behaves, or what an agent should expect after invocation. The description is adequate for basic awareness but incomplete for reliable autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%, so the structured schema already documents most parameters like intensity, scale, title, and subtitle. The description adds contextual meaning to 'query' by framing it as a visual scene query and reinforces the action enum values, but it does not explain the 'draft' parameter or how the action selection interacts with the optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('apply') and resource ('CapCut editing action') and lists the exact action types it supports. The phrase 'matching a visual scene query' clearly distinguishes it from sibling tools like capcut_apply_filter or capcut_apply_effect, which apply specific named effects rather than auto-selecting based on a scene description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for cases where a visual scene query should automatically drive the choice of editing action. However, it does not explicitly say when to prefer this over the more direct sibling tools like capcut_apply_filter or capcut_add_lower_third, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the risk signal; 'undocumented ops' and 'use with care' warn that behavior is unstable and potentially harmful. However, it does not specify what side effects may occur, whether changes are persisted or need capcut_save, or whether the patch is validated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence front-loads the risk and action; every phrase earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a raw mutating tool with no annotations, no output schema, and 0% parameter documentation, the description is too thin to let an agent invoke it confidently. Critical missing context includes return value, error behavior, validation/isolation, and the save model; 'undocumented ops' explains why details are absent but does not supply them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there are no descriptions on draft/patch, so the description is the only source of semantics. It tells the agent the patch is a JSON patch and that it is deep-merged into draft_content, but it never explains the expected structure of the draft string, how patch paths are addressed, or what a valid patch looks like.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('deep-merge'), a target ('draft_content'), and the patch input; 'Advanced escape hatch' immediately flags it as the raw, undocumented sibling distinct from the high-level capcut_* tools. This is far more informative than a tautological name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'Advanced escape hatch' and 'undocumented ops' clearly imply this is the last-resort tool when no high-level sibling operation covers the needed change. It stops short of naming alternatives or explicit when-not-to-use conditions, but the context is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the safety disclosure burden and does so with an explicit 'Read-only' statement. It also adds useful behavioral/return detail by listing what will be returned. It does not cover error cases or payload size, but these are less critical for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The main content is front-loaded in the first sentence, and 'Read-only' reinforces the safety profile without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no annotations and no output schema, the description gives a useful summary of the return content. However, it omits explanation of the 'draft' parameter format and does not fully compensate for the absent output schema and parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'draft' parameter has zero schema coverage, and the description does not explain whether it should be a draft ID, name, path, or other identifier. It merely repeats 'draft' from the parameter name, leaving the agent to infer the expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific verb (Read) and resource (draft), and enumerates the contents: canvas, fps, tracks, and every segment with id, media, times, and layer. The read-only qualifier distinguishes it from the many mutating sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when the agent needs to inspect a draft's full timeline without modifying it, reinforced by 'Read-only.' However, it does not explicitly contrast with sibling tools like capcut_list_drafts or capcut_inspect_edit, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 usefully discloses the catalog scope and sample search terms, but it does not state the return format, matching behavior, pagination, whether the search is cached/local, or confirm the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler. It front-loads the core action and resource, then adds helpful scoping detail through examples and catalog size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers all parameters, so the description is mostly adequate. However, with no output schema and no annotations, the agent still lacks explicit information about what the search returns or how results are ordered/limited beyond the schema default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters already have descriptions in the schema, so the baseline is 3. The description adds example search terms that align with the query parameter but does not provide additional parameter-specific semantics beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: search the CapCut color filters catalog. It includes concrete examples like 'Vintage 90s' and 'Teal & Orange' and the scale (~450+ LUTs/looks), which clearly differentiates it from sibling list tools such as list_effects or list_transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to search or browse CapCut's color filter catalog before applying a filter. It does not explicitly mention alternatives or when not to use it, but the phrasing makes the intended use obvious enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It accurately describes the effect (blur or solid color behind a clip) and adds useful detail like Gaussian and reframing. Still, it does not disclose that the operation mutates the draft, whether it overrides existing background settings, or whether it is reversible, which are meaningful gaps 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action, the two modes, the target (behind a clip), and the use case. There is no filler or redundancy, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description plus schema cover the parameters and core behavior reasonably well. However, it omits explicit guidance on when to use this versus capcut_set_canvas, any prerequisites, and side-effect disclosure, so the overall context 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%), with type, color, segmentId, and blurRadius documented; only draft lacks a schema description. The description adds the concepts of Gaussian blur and solid color that map to the type enum, but it does not clarify the draft parameter or the type/color dependency beyond what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Apply), a concrete resource (Gaussian canvas background blur or solid color), and a placement condition (behind a clip) with a clear purpose (vertical/horizontal reframing). This distinguishes it from sibling tools like capcut_set_canvas and makes the function immediately clear 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for vertical/horizontal reframing' provides a clear context for when this tool is appropriate. However, it does not explicitly name alternative tools or state when not to use it, so the guidance is contextual rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does convey the destructive nature by saying unsaved session edits are dropped and the draft is reloaded from disk. It could be more explicit about potential data loss, but the core side effect is evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. The key behavior is front-loaded and every word contributes to understanding the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive operation with no output schema, the description gives enough to understand the action and its effect. It does not cover edge cases like what happens if there are no unsaved edits or what the return value is, but those are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, 'draft', but zero description coverage, and the tool description does not compensate by explaining the parameter's format or meaning. The phrase 'reload the draft' only weakly hints that 'draft' identifies which draft to operate on, leaving the agent without clear parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action, 'Drop unsaved session edits and reload the draft from disk', with a clear resource (draft/session edits). It distinguishes itself from sibling tools like capcut_save or capcut_read_timeline by specifying that unsaved changes are discarded.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you want to abandon unsaved in-memory edits and restore the last saved draft state. It does not explicitly name alternatives or state when not to use it, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly indicates a read-only listing operation, specifies the source directory, and names two result attributes. It does not explicitly state return format or sorting/scope details, but the behavior is unambiguous for a zero-parameter list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler. It packs the action, resource, exact path, and key output fields efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The simple tool needs no parameters, but with no output schema the description should more explicitly state what the returned draft entries contain (e.g., draft identifiers/names) rather than only duration and lock status. The sentence is a good start but leaves the full return contract implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description need not add parameter meaning. The schema covers the empty parameter set, and the description provides no conflicting information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), resource ('CapCut drafts'), exact location, and output fields ('duration and lock status'). This distinguishes it from sibling list tools focused on effects, transitions, filters, and stickers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the name and description: call it to enumerate available CapCut drafts before choosing one to edit. However, there is no explicit guidance about when to prefer it over read_timeline or other sibling tools, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of side effects. It explicitly warns that empty:true clears all clips/tracks, which is the key behavioral risk. It also implies the base draft is left intact by calling the operation a copy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the purpose and the critical parameter behavior with no filler. The operation is front-loaded before the parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter clone tool with no output schema, this is nearly complete: it explains the operation, the scaffolding use, and the destructive option. It stops short of specifying what an omitted empty value means or details about naming, but those are inferable from context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully: base is the draft folder being copied, newName is the destination name, and empty is defined as clearing all clips/tracks. Every parameter receives meaningful semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States exactly what the tool does: copies a draft folder to a new name. The verb and resource are specific, and this operation is distinct from the sibling tools that modify, read, or add content to a draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description frames the tool as 'valid scaffolding' and explains that empty:true is 'for a fresh build', giving clear use context. It does not explicitly name alternatives or exclusions, but the intended use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/daviilpzDev/arkeonix-capcut-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server