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, but it only states the basic action. It does not mention that adding audio mutates the draft, that omitting trackIndex creates a new track, that atSec can append after the last clip, or what side effects or return values to expect.

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

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

The description is a single short sentence with no repetition, which is concise in form. However, for a 14-parameter tool it is too terse to be considered well-sized, and the phrase 'at a time' is vague. It avoids bloat but sacrifices useful content.

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

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

With no annotations, no output schema, low parameter coverage, and a one-sentence description, the tool is far from complete enough for correct invocation. The agent has no information about required draft context, track behavior, timing semantics beyond what the schema partially covers, or the result of the operation.

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

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

Schema description coverage is only 36%, leaving 9 of 14 parameters undocumented. The description adds no parameter-level meaning at all and does not compensate for the missing schema descriptions, so an agent cannot infer the semantics of file, draft, posX, posY, scale, speed, volume, opacity, rotation, or other fields.

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

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

The description identifies a specific action and resource: 'Add an audio clip' to a track, which is enough to distinguish it from sibling tools like capcut_add_video, capcut_add_image, or capcut_add_text. The phrase 'at a time' is somewhat ambiguous about timeline placement, but the core purpose is still clear.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as a draft ID, track selection, or audio file requirements. Sibling tools are not referenced and no exclusion criteria are given, leaving the agent to infer appropriate usage from the tool name alone.

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

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

The description usefully discloses partial-update behavior: omitting a fade parameter leaves it unchanged. However, with no annotations provided, the description carries the full burden of behavioral transparency, and it does not mention constraints, side effects, what happens if both fade parameters are omitted, or whether the operation is reversible.

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

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

Two short sentences carry the essential operation and the key behavioral nuance. Every word earns its place, and the main action is front-loaded.

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

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

For a simple, targeted mutation this is mostly adequate: the target, operation, and edit semantics are clear. Still, missing parameter context for 'draft', no annotation safety profile, and no mention of what the operation does to unsupported segments keep it from being fully complete.

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

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

Schema coverage is 0%, so the description must compensate. It adds meaning for fadeInSec/fadeOutSec through the phrase 'fade-in/fade-out duration' and for segmentId through 'segment', plus clarifies optionality. But 'draft' is left unexplained, and units or value ranges for the fade durations are not stated.

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

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

The description uses a specific verb ('Set') and resource ('audio / audio-carrying segment') and clearly states the operation is about fade durations. It is unambiguously distinct from siblings like capcut_add_audio, which adds audio, and capcut_set_props, which is a generic properties tool.

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

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

The intended use is implied: when the agent wants to modify fade-in/fade-out durations on an existing segment. However, it does not explicitly state when to prefer this over generic alternatives like capcut_set_props or capcut_raw_patch, nor does it mention 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.

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

The description discloses a key behavioral trait: the operation replaces any existing filter on the segment. This is important side-effect information that an agent needs to know. It also explains the intensity parameter's default behavior. With no annotations provided, the description carries the full burden, and it does a good job of disclosing the destructive replacement behavior. It could add more context about whether the operation is reversible or requires a saved draft, but the replacement warning is the most critical behavioral detail.

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

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

The description is a single, dense sentence that front-loads the core action and then adds the two most important qualifiers: the filter source and the replacement behavior. Every word earns its place, and the intensity clarification is efficiently appended. No wasted words or redundant information.

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

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

For a tool with 4 parameters, no output schema, and no annotations, the description covers the essential context: what the tool does, where the filter comes from, the destructive replacement behavior, and the intensity semantics. The only minor gap is not explaining what 'draft' and 'segmentId' refer to, but those are inferable from the tool's purpose and sibling context. The description is complete enough for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that 'name' refers to a filter from capcut_list_filters, which is essential semantic context not in the schema. It also explains the 'intensity' parameter's range and default behavior. However, it doesn't explain 'draft' or 'segmentId' semantics, though those are fairly self-explanatory from their names and the tool's purpose. The description adds significant value for the two most ambiguous parameters.

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

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

The description states a specific verb ('Attach'), a specific resource ('a real CapCut filter'), and a clear scope ('to a segment'). It also distinguishes itself from other add tools by specifying the filter source (capcut_list_filters) and the replacement behavior. This clearly differentiates it from siblings like capcut_add_transition or capcut_add_mask.

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

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

The description explicitly says to use a filter from capcut_list_filters, which is a clear usage guideline. It also states the replacement behavior ('replacing any filter already on it'), which tells the agent when this tool is appropriate. However, it doesn't explicitly say when NOT to use it or name alternatives for other operations, so it falls slightly short of a 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention side effects, whether the draft must be saved separately, how the image is positioned, or what happens to the existing timeline. 'Add an image at a time on a track' only restates the basic action without meaningful behavioral context.

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

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

The description is a single short sentence with no redundancy, but it is under-specified rather than genuinely concise. It fails to convey essential details that an agent needs, making it more a placeholder than a useful definition.

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

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

Given the tool's complexity—14 parameters, no annotations, and no output schema—the description is clearly incomplete. An agent cannot safely invoke this tool correctly without additional information about required parameters, defaults, and side effects.

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

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

With 14 parameters and only 36% schema description coverage, the description must compensate but does not. It loosely maps to atSec and trackIndex via 'at a time' and 'on a track', but it omits the required file and draft parameters and provides no guidance for positioning, scaling, opacity, rotation, or other properties.

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

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

The description states a specific verb ('Add') and resource ('an image'), and mentions a time and track, which identifies the core action. However, it does not explicitly differentiate itself from sibling tools like capcut_add_video or capcut_add_sticker, so it lacks clear sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description only states what the tool does, leaving the agent to infer usage context from the tool name and the large sibling list.

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

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

With no annotations, the description carries the full burden. It discloses that it creates real per-property animation (not static) and that it can add or replace keyframes. However, it does not mention mutation of the draft, persistence, or any error conditions, which are important for a mutating tool without annotation coverage.

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

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

The description is a single paragraph that front-loads the core behavior, then gives a usage tip and the enum list. It is concise and to the point, though it could be better structured with separate sentences for each key point.

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

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

For a mutation tool with no output schema and no annotations, the description should explain more: whether changes are saved automatically, what happens on conflicting keyframes, and any time constraints. The description leaves these out, making it incomplete for an agent to call it correctly.

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

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

Schema coverage is 0%, so the description must explain all parameters. It explains atSec and value indirectly through the usage tip ('different atSec/value') and lists the property enum, but does not define units, ranges, or the roles of draft and segmentId. This is insufficient for a 5-parameter tool with no schema descriptions.

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

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

The description states a specific verb (add/replace), a clear resource (keyframe on a segment property), and distinguishes it from static value setting. It also lists the allowed property enum, making the tool's scope unambiguous and different from siblings like set_props or remove_keyframes.

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

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

It explicitly instructs to call twice with different atSec/value to animate, which is a clear usage pattern. It implies the tool is for animation rather than static values but does not mention alternatives or when not to use it, leaving a minor gap.

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

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

No annotations are provided, so the description carries the burden. It discloses the destructive replacement of an existing mask and specifies fraction ranges for several parameters. However, it does not mention potential side effects, permission requirements, or what happens if the segment lacks a mask, leaving some gaps.

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

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

A single sentence that is front-loaded with the primary action and includes the critical note about fraction ranges. Every word earns its place; no fluff.

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

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

With 11 parameters, no output schema, and no annotations, the description is sparse. It covers the core action and some parameter types but omits return behavior, error handling, and detailed semantics for many parameters, making it incomplete for confident invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that several parameters (center/width/height/rotation/feather/roundCorner) are fractions, and names the source for 'name', but it leaves draft, segmentId, invert, centerX, centerY, and others undefined. Given 11 parameters, this is insufficient.

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

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

The description clearly states the tool's function: attaching a mask shape to a segment, explicitly referencing the source (capcut_list_masks) and the replacement behavior. This distinguishes it from sibling tools like add_filter or add_transition, which have different purposes.

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

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

It indicates when to use the tool (to attach a mask) and that it replaces existing masks, but does not explicitly mention when not to use it or alternatives (e.g., for adjusting mask properties, use set_props). The context is clear but lacks exclusions.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. It does explain that there is no bundled sticker catalog and that the resource_id must be sourced from a draft, which is important. However, it does not mention potential side effects like track creation (which is implied by 'placed on a new or existing sticker track') or what happens to the sticker if the draft is invalid. Since annotations are absent, this is a moderate gap.

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

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

The description is concise, about two sentences, and front-loads the most critical behavioral detail (resource_id acquisition) early. It avoids fluff but could be slightly more structured to explain parameter defaults. Overall efficient.

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

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

Given the complexity (14 parameters, 2 required, no output schema, no annotations), the description provides essential context for the required parameter (resourceId) but leaves many optional parameters and potential behaviors unexplained. For an agent to use it correctly, it would need to infer parameter behaviors from the schema or examples. This feels incomplete for a tool that creates timeline items.

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

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

Schema coverage is only 36%, so the description must compensate for undocumented parameters. It adds value by explaining the resourceId's source and the atSec default behavior. However, many parameters (posX, posY, scale, etc.) are not explained in the description, forcing the agent to rely on their names or the schema. The description does not fully compensate for the low coverage.

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

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

Clearly states the tool's action (add a sticker), the resource used (resource_id), and the target (new or existing sticker track). It even explains how to obtain the resource ID, which is a crucial domain-specific detail. This clearly distinguishes it from other add tools like capcut_add_text or capcut_add_image.

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

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

The description explains when to use this tool (when you have a resource_id from an existing draft) and implicitly that it is the only way to add a sticker since there is no bundled catalog. It does not explicitly name siblings, but the rationale is clear and provides context for when this tool is appropriate.

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

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

There are no annotations, so the description must disclose behavioral traits. It does reveal one hidden requirement (the draft must already contain a text layer), but it does not say whether this mutates the draft, whether saving is required afterward, or what side effects occur on existing timeline data. For a mutation tool this is a substantial transparency gap.

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

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

The description is a single tight sentence with no filler; the core purpose is front-loaded and the prerequisite is placed immediately after. The reference to CAPCUT_TEMPLATE_DRAFT is terse but not wasteful, though it is unclear what that symbol points to.

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

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

A 9-parameter mutation tool with no annotations and no output schema cannot be adequately described in one sentence. The description omits semantics for the majority of parameters, return behavior, and side effects, leaving an agent with substantial ambiguity.

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

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

With only 22% schema description coverage, the description needed to explain most of the 9 parameters, but it only helps define 'draft' as a text template. Parameters such as posX, posY, durSec, fontSize, and trackIndex remain undocumented in both schema and description.

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

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

The description opens with a specific action and object: 'Add a text overlay,' which clearly identifies what the tool does. The template requirement adds useful context, but it does not explicitly contrast the tool with sibling add_* tools such as add_sticker or add_video, so differentiation relies mostly on the tool name.

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

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

The only usage guidance is the prerequisite that a text template draft is needed and the pointer to CAPCUT_TEMPLATE_DRAFT. It gives no guidance about when to choose this tool over the many sibling add_* tools, and it notes no exclusion criteria.

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

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

There are no annotations to fall back on, and the description only states 'Add a new track' without disclosing behavioral details such as whether existing content is affected, what constitutes a valid track, or what the result of the operation looks like. 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.

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

The description is a single concise sentence that front-loads the action and enumerates the track types. However, it is too terse to fully inform the agent; brevity is achieved at the cost of essential details.

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

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

Given the existence of sibling add_* tools, the description does not clarify the relationship or when to prefer this generic tool. With 3 parameters, no annotations, and no output schema, the description is too minimal to provide complete context for correct invocation.

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

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

The schema has 0% description coverage, so the description must compensate, but it only lists the type enum which already appears in the schema. It provides no explanation of the 'name' or 'draft' parameters, leaving their meaning and format unclear.

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

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

The description clearly states the verb 'Add' and the resource 'track', with an explicit list of allowed types (video, audio, text, sticker). However, it does not differentiate this tool from sibling tools like capcut_add_video, capcut_add_audio, etc., which likely create specific track types.

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

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

No guidance is provided on when to use this tool versus the more specific add_* sibling tools. It does not mention alternatives, exclusions, or typical use cases.

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

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

With no annotations, the description carries the burden of behavior. It adds non-obvious constraints: the name must be a real transition from capcut_list_transitions, and the effect is anchored to the immediately following segment on the same track. However, it does not disclose side effects on the draft, failure behavior when no following segment exists, or whether the change requires save/undo.

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

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

One sentence, front-loaded with the core action and placement, no filler. Every phrase earns its place.

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

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

The definition covers the main intent and the key prerequisite (list_transitions), and the output schema is absent so no return contract is promised. It lacks error/edge-case guidance and explicit origin of draft/segmentId, leaving the agent to infer some semantics from sibling tools.

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

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

Schema describes only durationSec; the three required params are bare. The description compensates partially by defining name as a valid transition from list_transitions and segmentId as 'this segment' with a following segment on the same track. draft is left unexplained, so compensation is incomplete.

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

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

States a specific operation ('Attach') on a specific resource (a CapCut transition) and a precise placement (between this segment and the next on the same track). It is clearly distinct from sibling tools like add_filter or add_mask, and points to list_transitions as the source of valid transition names.

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

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

The description conveys when it applies: adding a transition to a segment and getting the transition from capcut_list_transitions. It gives clear context but does not explicitly say when not to use it or mention alternatives.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does add one meaningful fact: the operation is a session edit and requires capcut_save to persist. However, it does not disclose whether clips are inserted vs replaced, how track selection behaves, or any side effects on existing clips.

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

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

The description is a single front-loaded sentence with no wasted words. The core action and the persistence requirement are both stated efficiently. It is slightly too terse given the tool's complexity, but as conciseness alone it is well structured.

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

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

This is a complex 14-parameter tool with no annotations and no output schema, and the description leaves most operational behavior unstated. An agent is not told how omitted tracks are handled beyond the schema, what the default duration means, or what happens on success/failure. The session-save note helps but is far from enough for safe invocation.

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

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

Schema description coverage is only 36%, and the description provides no parameter-level meaning whatsoever. With 14 parameters and 12 undocumented, an agent cannot understand how file, posX, posY, scale, speed, volume, opacity, rotation, or trackRenderIndex behave. The description must compensate for the schema gaps and does not.

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

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

The description clearly states the verb ('Add'), the resource ('a video clip'), and the target ('on a track'). It also distinguishes this tool from siblings like capcut_add_image, capcut_add_audio, and capcut_add_text by naming the media type explicitly.

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

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

There is no guidance about when to choose this tool over alternatives. With 27 siblings, including several other add_* tools, the description gives no exclusions, no alternative names, and no conditions for selecting it. The media-type naming implies some distinction, but the tool never says 'use this for video clips instead of add_image/add_audio'.

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

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

With no annotations, the description carries the burden of 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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It does well by explaining the critical ripple effect: later segments shift earlier to close gaps, and rippleAllTracks extends this to every track. It could add that deletion is permanent or reversible, but the current explanation of the destructive and gap-filling behavior is strong.

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

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

Two tightly written sentences with no filler. The core action is front-loaded, and the conditional ripple behavior is explained efficiently without redundancy.

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

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

The description is fairly complete for a straightforward deletion tool: it covers the core operation, the two behavior-modifying booleans, and the gap-closing consequence. It lacks a definition of 'draft' and does not mention output or error behavior, but the essential call semantics are present.

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

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

Schema description coverage is 0%, so the description must compensate. It explains ripple and rippleAllTracks meaningfully and segmentId is self-evident, but it does not clarify the required 'draft' parameter beyond its name. The description adds real value for two of the four parameters, but leaves the primary context parameter undocumented.

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

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

The description opens with a specific verb and resource, 'Remove a segment,' which clearly identifies the operation as deleting a segment from a CapCut draft. It goes beyond a bare restatement by explaining the ripple behavior, though it does not explicitly contrast itself with sibling tools like trim_segment or split_segment.

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

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

The usage is implied: an agent should call this when a segment needs to be removed, and no alternative deletion tool exists among the siblings. However, there is no explicit when-to-use or when-not-to-use guidance, nor any comparison with alternatives like move_segment or trim_segment.

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

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

With no annotations provided, the description carries the full burden of 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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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

With no annotations, the description carries the behavioral burden. It discloses important matching semantics (case-insensitive, space-insensitive, substring) and the omit-query listing behavior, which is genuinely useful. It does not describe the exact return shape or no-match behavior, but for a read-oriented search tool the core behaviors are covered.

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

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

The entire definition is one tight, front-loaded sentence with no filler. Every clause adds operational information the agent needs.

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

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

For a tool with one optional parameter and no output schema, the description covers invocation semantics and matching behavior well. The only minor gap is that it does not describe the result item shape or ordering, though 'first matches' implies an ordered list.

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

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

The schema only defines 'query' as an optional string with zero description coverage. The description fully compensates by explaining that the query is a filter name substring and that matching is case/space-insensitive, plus the behavior when the query is omitted.

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

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

The description states a specific verb ('Search') and a specific resource ('the bundled catalog of 474 real CapCut filters'), then narrows the operation with case/space-insensitive substring matching. This clearly differentiates it from sibling tools like capcut_list_masks, capcut_list_transitions, and capcut_list_drafts.

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

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

The description implies the tool is for discovering filter matches, and the 'Omit query to see the first matches' line gives a usage variant. However, it never explicitly states when to use this versus alternatives like capcut_add_filter, nor does it provide any exclusion criteria.

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

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

With no annotations, the description itself must convey behavior. 'List' clearly signals a read-only operation, and the stated count of 9 is a useful behavioral detail. It does not describe the return format, but for a 0-parameter listing tool this is a minor gap.

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

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

The entire description is one precise sentence with no filler. It immediately states what the tool lists and how many items are available.

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

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

For a trivial 0-parameter listing tool, the description is substantially complete: it identifies the resource and the expected output count. It could be slightly more helpful by noting that the returned mask shapes can be used with capcut_add_mask, but this is not essential for correct invocation.

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

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

There are zero parameters, so parameter semantics are not applicable. The baseline of 4 applies: no parameter information is needed, and the description does not need to compensate for any undocumented parameters.

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

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

The description 'List the 9 available mask shapes' uses a specific verb and resource, and even states the exact count. It clearly distinguishes this from sibling list tools like capcut_list_filters 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.

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

The usage is implied: an agent would call this when it needs to know what mask shapes are available. However, there is no explicit guidance about when to use this versus capcut_add_mask or other siblings, and no mention that it could supply valid values for adding masks.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that this is a non-mutating search over a fixed bundled catalog, defines the matching rule, and explains the default listing behavior when query is omitted. It does not explicitly state 'read-only' or describe side effects, but the wording strongly implies a safe query operation.

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

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

Two sentences with no filler. The first sentence front-loads the operation, resource, and key search semantics; the second clarifies the parameter default. Every word earns its place.

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

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

For a one-optional-param search tool with no output schema or annotations, the description covers purpose, matching behavior, and invocation default. The only gap is that it does not describe the shape of the returned matches (e.g., whether IDs are included for use with capcut_add_transition), but the core usage is clear.

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

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

Schema coverage is 0%, so the description must explain the lone 'query' parameter, and it does so thoroughly: name-based, case/space-insensitive substring matching, and optional with a well-defined default ('Omit query to see the first matches'). This fully compensates for the bare schema that only lists type string.

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

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

The description uses a specific verb ('Search') and names the exact resource: 'the bundled catalog of 116 real CapCut transitions'. It also specifies matching semantics (case/space-insensitive substring), which clearly distinguishes it from mutating siblings like capcut_add_transition and from the other capcut_list_* family tools.

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

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

It gives clear usage context: query is an optional name substring, and omitting it returns the first matches. However, it does not explicitly name alternatives or state when not to use this tool, leaving the distinction from capcut_add_transition and sibling list tools implied rather than spelled out.

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

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

With no annotations, the description carries the full 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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate. It 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.

Does 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.

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

There is no guidance on when to use this tool versus 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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

With no annotations, the description carries the disclosure burden. It adds a meaningful behavioral trait by stating that the result includes pending unsaved edits from this session, which is important context for an agent deciding whether to trust the returned data as current. The verb 'Read' signals a non-mutating operation, though error behavior and access prerequisites are not covered.

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

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

Two sentences, front-loaded with the core action, with every clause earning its place. The return contents are compactly listed in parentheses and the unsaved-edits caveat is stated in a second short sentence with no filler.

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

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

For a one-parameter read tool with no output schema, the description gives a strong inventory of the returned data and the key session caveat. It is mostly complete for invoking the tool correctly, though it would be stronger if it explained where the 'draft' identifier comes from.

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

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

The schema has 0% description coverage and the only parameter is an undocumented 'draft' string. The description merely says 'a draft,' which adds no meaning beyond the property name; it does not clarify whether draft is an ID from capcut_list_drafts, a path, or some other identifier.

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

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

The description opens with a specific verb and resource ('Read a draft') and enumerates exactly what will be returned: canvas, fps, tracks, and every segment with id/media/times/layer. This makes the tool's purpose unambiguous and visually distinct from siblings like capcut_list_drafts.

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

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

The phrase 'Reflects any pending unsaved edits from this session' provides clear context for when this tool is relevant: when the agent needs the current in-session state of a draft. However, it never explicitly says when to prefer this tool over alternatives such as capcut_list_drafts or capcut_save, so it stops short of full routing guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond the name by explaining that removal reverts the property to a static value from clip/set_props, which is a key side effect. It does not mention error handling, idempotency, or what happens if no keyframes exist, but for a simple removal operation the core behavior is adequately disclosed.

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

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

The description is a single sentence that leads with the action and specifies the scope and result. Every word adds value, with no filler or redundancy. It is concise and front-loaded, making it easy for an agent to quickly grasp the tool's purpose.

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

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

For a simple removal tool, the description covers the main behavior, the target property, and the revert outcome. It does not mention edge cases, error behavior, or return values, but given the absence of an output schema and the simplicity of the operation, the description is reasonably complete. The sibling tools (add_keyframe, set_props) provide context, and the description aligns well with that ecosystem.

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

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

The input schema has 0% description coverage, so the description must compensate by explaining the parameters. It mentions 'property' and 'segment' implicitly, but does not explicitly name the parameters or explain 'draft'. The enum values for property are self-explanatory, but the description fails to give complete parameter semantics, especially for draft and the relationship between parameters. It partially adds meaning but not enough to fully bridge the gap.

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

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

The description clearly states the action ('Remove all keyframes') and the target ('for one property on a segment'), which distinguishes it from the sibling capcut_add_keyframe. It also specifies the scope (all keyframes for a single property) and the result (reverts to a static value), leaving no ambiguity about what the tool does.

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

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

The description gives clear context on what the tool accomplishes and even notes the source of the static value (clip/set_props), which implies when it is appropriate to use. However, it does not explicitly mention when not to use it or name alternative tools for removing individual keyframes or handling other scenarios, so it lacks explicit exclusionary guidance.

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

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

With no annotations, the description carries the full 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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate. It explains 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.

Does 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.

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

The description implies when to use the tool: when 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.

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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate for the 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.

Does 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.

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

No guidance is given on when to use this tool versus alternatives. 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.

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.

Is 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.

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

For a mutation tool with no annotations, no output schema, and 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.

Does 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.

Does 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.

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

The description implies when to use the tool—when a 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.

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 mutation (change start/duration/in-point) and the ripple effect (shifting later segments). However, it does not mention whether the edit is reversible, if it requires saving (capcut_save), or any error cases. The ripple explanation is valuable but other operational behavior is missing.

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

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

The description is a single, tightly packed sentence: the core action first, then the ripple qualifier. No wasted words, front-loaded with the primary purpose, and the ripple explanation is concise. Perfectly structured for quick scanning.

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

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

For a tool with 7 parameters and no output schema, the description covers the core behavior and ripple effect but omits operational details such as whether changes are persisted immediately, the need to call capcut_save, or error handling for invalid segment IDs. It is adequate for basic usage but not fully complete for a complex edit operation.

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

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

Schema description coverage is 0%, so the description must compensate. It maps atSec/durSec/srcStartSec to start/duration/source in-point and explains ripple and rippleAllTracks. However, it does not clarify that these parameters are optional (only draft and segmentId are required) or how they interact when multiple are provided. The ripple semantics are explained but optionality and interplay are left implicit.

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

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

The description clearly states the verb 'Change' and the resource: segment start, duration, and source in-point. It specifies seconds and distinguishes itself from siblings like move_segment (which repositions) and split_segment (which divides) by focusing on trim-like edits. No ambiguity about what the tool does.

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

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

The description implies usage for trimming operations but does not explicitly state when to use this tool over alternatives like move_segment or split_segment. It provides context about ripple behavior but no exclusions or mention of sibling tools. Usage is clear from the action but not fully guided.

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

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

With no annotations, the description carries the behavioral burden and does a reasonably good job: it discloses a 20-step history limit and that already-saved state is not touched. It does not discuss error behavior or whether the operation can be reversed beyond the stated limit, but the key persistence behavior is surfaced.

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

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

The description is two short sentences, front-loads the operation and scope, and contains no filler. Every clause contributes information about when and how the undo operates.

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

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

For a tool with one required parameter, no output schema, and no annotations, the description is incomplete: it never explains what to pass for 'draft' or what the tool returns. The undo semantics are clear, but a caller cannot reliably construct a valid invocation from this text alone.

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

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

The single required parameter, 'draft', is a string with 0% schema coverage and is not mentioned in the description. An agent cannot tell whether it is a draft ID, a path, a JSON object, or the content to act on, so the parameter semantics are effectively unknown.

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

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

The description clearly states a specific verb ('Undo'), the resource ('the last edit'), and scopes it to the current session with a 20-step limit. It does not explicitly name a sibling alternative, but the persistence qualifier distinguishes it from save/discard operations.

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

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

It gives clear context: use this after a mistaken edit in the current session, up to 20 steps back. The statement that saved-to-disk content is unaffected communicates an important boundary, though it does not name alternatives or list exclusion cases such as empty undo stacks.

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

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

No annotations are provided, so the description must disclose behavior. It states what it checks but does not indicate whether the operation is read-only, what the return value looks like, or whether it modifies the draft. 'Check' implies non-destructive, but the absence of side-effect or outcome details leaves the agent uncertain.

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

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

The description is a single concise sentence that front-loads the tool's purpose and enumerates the validation checks without redundant words. Every element earns its place.

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

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

With no annotations and no output schema, the description should explain what the tool returns or how to interpret validation results. It does not, and it also lacks usage context. The simple single-parameter tool is underspecified for an agent to fully understand the tool's role in a workflow.

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

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

The schema provides only a required string parameter 'draft' with 0% description coverage. The description clarifies that the draft is 'in-session', which adds some meaning. However, it does not explain the expected format (e.g., JSON string, ID) or how the parameter relates to the in-session state, so compensation is partial.

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

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

The description uses a specific verb ('Check') and identifies the resource ('draft') plus the exact validation criteria (overlaps, duplicate ids/render_index, missing media). It clearly distinguishes this from sibling tools like capcut_read_timeline or capcut_set_props by focusing on validation rather than reading or editing.

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

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

The description gives no guidance on when to use this tool versus siblings (e.g., before saving, after edits) and does not mention any alternatives or exclusions. It only implies 'use to validate the draft' but provides no context for decision-making.

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