Skip to main content
Glama

AdsTurbo

video_extend

视频延长(在源视频末尾追加 N 秒)

仅支持 seedance-2.0 模型基座。 源视频二选一:workspace_id(内部)或 video_url(外部);同时传 / 同时空均报错。 duration 为增量秒数:原 8s + duration=4 → 输出 12s。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNo仅支持 `seedance-2.0`。seedance-2.0
ratioNo
promptNo
durationNo在源视频末尾追加的秒数;范围 4~15,默认 15。
video_urlNo
resolutionNo
callback_idNo自定义追踪 ID,webhook URL 后台配置
workspace_idNo
idempotency_keyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare the safety profile (not read-only, open-world, not idempotent, non-destructive). The description adds real value with the source-video mutual-exclusion rule and its error behavior, but says nothing about the asynchronous job/webhook delivery implied by callback_id and the get_work_status siblings, nor about what is produced.

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

Conciseness4/5

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

Four tight lines, front-loaded with the operation, then the model restriction, then the source rule and the duration semantics. No filler; each sentence carries a distinct constraint.

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

Completeness3/5

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

For a 9-parameter async video tool with no output schema and no required parameters, the definition covers the critical input rules but omits return/delivery behavior (polling vs webhook via callback_id) and several optional parameters. Adequate to call correctly, not complete.

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

Parameters3/5

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

Schema description coverage is only 33%, so the description must compensate, and it does explain the workspace_id/video_url exclusivity, the incremental meaning of duration, and the model restriction. But ratio, prompt, callback_id, and idempotency_key remain unexplained in both the schema and the description.

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

Purpose4/5

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

States a specific verb+resource plus scope: video extension by appending N seconds at the end of a source video. That is clearly distinct from video_generate (new video) or video_edit (modify existing), though no sibling is named explicitly.

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

Usage Guidelines3/5

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

Gives useful preconditions — only the seedance-2.0 base, and the either/or rule for workspace_id vs video_url with both/neither being an error. However it never says when to choose this tool over alternatives such as video_generate or video_edit, so routing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources