Replace a video track while keeping approved audio intact, then apply an explicit duration policy to control output length.
Replace video while preserving approved audio with explicit duration policy.
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | Yes | ||
| project_dir | Yes | ||
| audio_source | Yes | ||
| video_source | Yes | ||
| duration_policy | No | ||
| authorization_decision_ids | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.16.0Does 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 hints at a duration policy and preserving approved audio, but does not state what gets replaced or destroyed, whether the output overwrites anything, what authorization_decision_ids represent, or what permissions are required. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler, and it front-loads the action and the key constraint (preserve approved audio). The problem is under-specification rather than verbosity, so conciseness itself is strong.
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 6 parameters, no annotations, and 0% schema description coverage, the description omits nearly all behavioral and parameter context an agent would need. Output schema exists, so return values need not be explained, but the remaining gaps—duration policy semantics, authorization IDs, required inputs—make it materially incomplete for a replacement 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 6 parameters and 0% description coverage, so the description should compensate. It mentions duration_policy by name and implies audio/video sources, but gives no format, allowed values, or meaning for duration_policy, authorization_decision_ids, project_dir, or output_path. The description adds only minimal meaning beyond the bare 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?
"Replace video while preserving approved audio" gives a clear verb (replace) and resource (video), and the audio-preservation qualifier hints at a body-swap operation. However, it never names or contrasts with any sibling tool such as video_merge, video_edit, or video_add_audio, and terms like "approved audio" and "body swap" are left undefined. This is a clear purpose but with no 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?
The description offers no when-to-use guidance, no conditions for choosing it over alternatives, and no prerequisites or exclusions. Usage is only implicit from the verb "replace." An agent must infer all routing decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.