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

Annotations already disclose readOnly=false and destructive=false. Description adds that it adds to the timeline and returns JSON confirmation, but does not provide richer behavioral context (e.g., side effects, mutation details). No contradiction with annotations.

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

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

Front-loaded with a clear summary and organized Args/Returns sections, but the Args list duplicates parameter descriptions already present in the schema, adding redundancy. It is acceptable but not as concise as it could be.

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 with 8 params and no output schema, the description covers the essential operation, parameter roles, and return type. It also explains extra_params passthrough and gives examples, though it omits error scenarios and detailed return structure.

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

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

Schema description coverage is 100%, and the description largely paraphrases schema definitions (e.g., start, end, volume, speed, effects). It adds minor clarifications like 'end defaults to full clip length' but those are already in the schema, so little new value.

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

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

Description states 'Add an audio clip (music, voiceover, sound effect) to an existing draft's timeline' with a specific verb and resource, and clearly distinguishes from siblings like capcut_add_text, capcut_add_video, etc.

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?

Indicates the audio is added to an 'existing draft' and that draft_id comes from capcut_create_draft, providing clear context. However, it does not explicitly state when not to use this tool or name alternatives, though siblings are obvious.

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 adds useful details like the time range behavior and that the effect is applied over a range, plus a return confirmation. However, it does not disclose whether the draft must be explicitly saved afterward (a sibling capcut_save_draft exists) or whether adding an effect overwrites existing ones. This is notable for a mutation tool without annotation hints.

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 front-loads a clear purpose but then includes a full Args list that duplicates the input schema, which is unnecessary and inflates length. The return line is brief, but the redundant parameter enumeration wastes tokens and reduces conciseness.

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 provides a basic return statement but omits important context about draft persistence (especially given capcut_save_draft) and effect layering or ordering. The rich schema covers parameters well, but the description is not fully complete for effective tool usage.

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 100%, and the description's Args section largely repeats the schema's property descriptions without adding new meaning. It does mention that params use null for defaults, but this is already in the schema. Thus it adds minimal value beyond the structured schema.

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

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

The description clearly states 'Apply a visual effect or filter to an existing draft over a given time range,' which specifies the exact action, resource, and scope. It also distinguishes itself from sibling add_* tools by focusing on visual effects/filters and time ranges.

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 its usage context ('existing draft') and mentions a relationship with capcut_create_draft, but it does not explicitly state when to prefer this tool over similar siblings like capcut_add_text or capcut_add_video_keyframe. No alternative names or exclusionary guidance is provided.

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

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

The description confirms the act of adding and mentions a JSON return, but does not disclose whether the operation persists immediately or requires a separate save (e.g., capcut_save_draft). Annotations already cover read-only/destructive/idempotent aspects, and the description adds only minimal extra context about side effects.

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

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

The opening purpose sentence is strong and front-loaded, but the 'Args' section duplicates the full parameter list from the schema at length, making the description verbose and repetitive. It could have omitted the redundant list and kept only the essential examples.

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 (11 parameters, nested objects, no output schema), the description covers the return value and parameter examples. However, it lacks workflow context such as the prerequisite of having an unsaved draft and the need to call capcut_save_draft afterward, which is important for a multi-step editing 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 coverage is 100%, so the baseline is 3. The description provides terse grouping and examples (e.g., 'zoom_in', 'fade_in') but largely restates the schema's parameter descriptions without adding substantial new meaning.

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

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

The description clearly states 'Add a static image (photo, graphic, generated art) to an existing draft's timeline,' using a specific verb and resource. It distinguishes itself from sibling add_* tools by explicitly targeting static images, not video, text, or audio.

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 static images in an existing draft, but does not explicitly say when to choose this over capcut_add_video or capcut_add_text, nor does it mention the need to save the draft later. It provides clear context but no exclusions or alternative 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?

Annotations already signal mutation (readOnlyHint=false) and open-world nature (openWorldHint=true). The description adds context that the sticker is placed on the timeline, requires an existing draft, and returns a JSON confirmation. It also discloses that extra_params allows passthrough of undocumented VectCutAPI fields, reinforcing the open-world behavior without contradicting annotations.

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 well-structured with a clear main sentence followed by Args and Returns sections. It is efficiently sized, though some parameter descriptions repeat schema information. The front-loaded purpose sentence earns its place, and overall the text is not bloated.

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

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

Given the 9-parameter complexity, rich schema, and annotations, the description provides necessary context: the target draft, timeline placement, and return type. It also directs to VectCutAPI docs for unmodeled fields. It lacks an explicit mention of how to obtain the sticker resource_id, but that may be covered by sibling tools or external assets, so completeness remains sufficient.

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

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

The input schema covers all 9 parameters with descriptions, achieving 100% coverage. The description's Args section largely paraphrases the schema without adding new meaning, particularly for position/scale/rotation which are already documented. Extra_params is also described in the schema in greater detail than the tool description, so the description adds minimal value beyond what the schema provides.

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 'Place a sticker asset on an existing draft's timeline,' naming the specific verb, resource, and context. This distinguishes it from sibling tools like capcut_add_text or capcut_add_video by focusing on sticker assets and an existing draft timeline.

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 adding stickers to an existing draft and mentions 'From capcut_create_draft' as a prerequisite. However, it does not explicitly state when to prefer this over sibling add_* tools or when not to use it, though the sticker-specific resource makes the intended use quite 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?

Annotations already establish mutation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds context by mentioning 'consistent styling and timing,' a JSON confirmation return, and extra_params passthrough behavior. It does not disclose whether existing subtitle tracks are overwritten or appended, but that 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 description is well-structured with a clear purpose statement, Args section, return value note, and exclusion note. It is appropriately sized, though the Args list repeats schema content, adding slight 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?

For a mutation tool with no output schema, the description covers key invocation information (required args, behavior, alternative tool). Missing details about whether the subtitle track replaces existing ones and what 'consistent styling' entails are not critical, given the annotations and full schema coverage.

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 100%, so the baseline is 3. The Args list mirrors the schema descriptions without adding new meaning. The extra_params parameter is already well-documented in the schema with examples and usage notes, so the description does not need to compensate.

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 ('Import an SRT subtitle file into an existing draft') and distinguishes itself from capcut_add_text by explicitly recommending that tool for single text overlays. This gives a clear verb+resource+scope.

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

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

Provides explicit when-not-to-use guidance with a named alternative: 'Don't use when: you only need a single one-off text overlay — use capcut_add_text instead.' Also implies the prerequisite of an existing draft via 'into an existing draft.'

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 already indicate a write operation (readOnlyHint=false) and open-world behavior (openWorldHint=true). The description adds valuable behavioral context by explaining the return value (JSON confirming addition and used optional features) and clarifying that extra_params are merged into the request body. It does not contradict annotations, but could further disclose side effects or permission requirements; still, it goes beyond what annotations provide.

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 well-structured with a concise purpose sentence, a categorized bullet list of parameters, a return note, and an exclusion clause. Every section is relevant and easy to scan, with no redundant or wasted 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?

Given the tool's complexity (17 parameters, nested objects, no output schema), the description covers the return value, parameter usage, prerequisite (draft_id from capcut_create_draft), and the alternative for subtitles. This is sufficient for an agent to invoke the tool correctly in most 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?

Schema coverage is 100%, so the baseline is 3. The description adds semantic grouping (basic styling, drop shadow, background panel) and explains extra_params as a passthrough for advanced VectCutAPI fields, enhancing the agent's understanding of how parameters relate. This goes beyond the schema alone, though not massively.

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

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

The description clearly states it adds a text element to an existing draft's timeline, with specific examples (title, caption, lower-third). It also distinguishes itself from the sibling subtitle tool via the 'Don't use when' clause, making its purpose unambiguous.

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 tells when NOT to use this tool (for burned-in subtitles from SRT) and directs the agent to capcut_add_subtitle instead. It also implies the prerequisite of an existing draft by referencing capcut_create_draft, which is clear contextual 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?

The description discloses that the tool modifies an existing draft and returns a confirmation JSON, which is useful. It also notes that video_url can be a local file path if supported by the backend. However, it doesn't mention side effects or failure modes beyond the schema, and the annotations already cover the non-read-only 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 structured with a clear opening sentence, an Args list, and a Returns line, making it easy to scan. It is somewhat repetitive of the schema but remains under control. The format helps the agent quickly locate parameter 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?

The description covers the core purpose, key parameters, and expected return value, which is important given the absence of an output schema. It also correctly notes the dependency on a draft created by capcut_create_draft. However, it lacks details on edge cases or advanced behaviors, but for a well-documented mutation tool this is adequate.

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 already provides full descriptions for all 11 parameters, including defaults and units. The description's Args list duplicates this information without adding new meaning, such as clarifying relationships between start/end or transform parameters. Since schema coverage is 100%, the description adds minimal value here.

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: adding a video clip to an existing draft's timeline, with specific use cases like background footage or B-roll. It distinguishes itself from sibling tools by explicitly targeting video clips, making the purpose unambiguous.

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 video clips by providing examples, which helps decide when to use it. It does not explicitly contrast with sibling tools for other media types, but the context is clear enough. No exclusion criteria are given beyond the implied 'for video only'.

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 already indicate it's a non-read, non-destructive operation. The description discloses the core behavior (adding keyframes) and the return value (JSON confirmation), but does not explain potential side effects like how existing keyframes are merged, whether the draft must be saved afterward, or whether values are interpolated in a particular way. This adds some value but lacks rich 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 has a clear opening sentence and a helpful example, but the argument list duplicates almost verbatim the schema descriptions. This redundancy makes it longer than necessary. The structure is logical, but not every sentence earns its place given the schema already documents all parameters.

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

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

Given the schema fully describes all parameters and annotations exist, the description provides enough to understand the tool's use: it targets an existing track, lists required arguments, includes an example, and states the return type. However, it does not cover the broader workflow (e.g., needing capcut_save_draft after adding keyframes) or the exact confirmation JSON structure. These are minor gaps, making it sufficiently complete for an agent.

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 100%, so the description's argument list is largely redundant. However, the example ('property_types=['scale_x','scale_y'], times=[0,2], values=['1.0','1.5']') concretely ties the parameters together, showing how to specify a multi-property animation over time. This adds relational meaning beyond the individual schema descriptions.

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

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

The description clearly states the action ('Add property keyframes') and the target ('an existing track' in a CapCut draft). It lists specific properties (scale, position, rotation, opacity) and distinguishes itself from sibling tools that add new media or text, focusing on animation keyframing.

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 says 'to an existing track,' which implies the track must already have been created via other tools like capcut_add_video. It provides clear context for when to use this tool (animating existing content) but doesn't explicitly mention alternatives or when not to use it. The example illustrates a common use case (zoom-in).

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 already indicate a write operation (readOnlyHint=false, idempotentHint=false). The description adds valuable context beyond annotations: it creates a draft and returns a draft_id that must be passed to subsequent calls. It also clarifies the ordering constraint. This is good transparency, though it doesn't discuss potential side effects like auto-save or external storage, which annotations' openWorldHint=true might warrant.

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 well-structured with clear sections (Args, Returns, Example) and front-loads the core purpose. Every sentence adds value: the ordering requirement, parameter defaults, return value, and example. No redundant or filler text.

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

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

For a tool with only two optional parameters and no output schema, the description is complete. It explains what it does, when to use it, what the return value is, and how to configure dimensions. It fully equips an agent to invoke the tool correctly and understand its role in the 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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by specifying that default dimensions are 1080x1920 (portrait) and that 1920x1080 is for landscape. This orientation guidance helps agents choose correct values without needing extra reasoning.

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: 'Create a new CapCut/Jianying video draft (project)'. It identifies the specific verb (create) and resource (draft), and distinguishes itself from sibling tools by noting 'This must be called first — every other capcut_* tool needs the draft_id it returns.' This makes its purpose unambiguous.

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 explicit when-to-use guidance: 'This must be called first' and 'Use when starting any new video project.' It also provides a concrete example ('make a 9:16 short' -> width=1080, height=1920). It clearly implies that sibling tools are for subsequent additions, making the usage context robust.

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 already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations: saving generates a 'dfd_' folder next to capcut_server.py and requires manual copying to the drafts directory. It also explains the return value shape, which is helpful since no output schema is present.

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 moderately sized but well-structured with labeled sections (Args, Returns, Note). Each sentence contributes useful information: purpose, usage timing, parameter source, return details, and side-effect notes. It is slightly verbose, but the structure makes it easy to scan, so it earns a 4.

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 tool with one parameter and no output schema, the description is quite complete. It explains the return value (result.draft_url and/or local folder path), the side effect (folder generation), how to use the output (copy to drafts directory), and idempotency. This covers the essential context an agent needs, though error handling is not discussed.

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 a description for draft_id ('The draft_id returned by capcut_create_draft') with 100% coverage. The description merely repeats this in the Args section ('From capcut_create_draft') without adding new meaning. Thus, the schema already carries the semantic weight, so the baseline score of 3 is appropriate.

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

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

The description opens with 'Save/finalize a draft so it can be opened in CapCut/Jianying,' which is a specific verb+resource that clearly distinguishes this from sibling tools that create or add content. The phrase 'Call this last, after adding all desired tracks/effects' further clarifies its role as the final step.

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 instructs 'Call this last, after adding all desired tracks/effects,' providing clear when-to-use guidance. It also notes that it is safe to call multiple times, which is useful. It does not explicitly state when not to use or name alternatives, but given the sibling context, the ordering is clear.

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