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.

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

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

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

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

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

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.

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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?

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.

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

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

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

Schema description coverage is 0%, and the description does not 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.

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

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

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

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

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

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

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

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

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

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?

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.

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

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

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

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

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

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.