Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jimeng-ai-mcp Generate a 10-second video of a fox running in snow, 16:9"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
即梦 AI 的 MCP 服务 — 让 Claude、Cursor 等 AI 助手直接调用即梦的图片/视频生成能力。
English | 中文
MCP（Model Context Protocol） 是 Anthropic 推出的开放协议，允许 AI 模型通过标准化接口调用外部工具和服务。
jimeng-mcp 将字节跳动旗下即梦 AI 的官方 Volcengine API 封装为 MCP 服务。接入后，你可以在 Claude、Cursor 等支持 MCP 的客户端里，用自然语言直接驱动即梦生成图片和视频——无需打开浏览器，无需手动上传，生成结果自动保存到本地。
Related MCP server: Jimeng AI Multimodal MCP
工具 | 能力 | 底层模型 |
| 文生图，支持 4.0 / 4.6 / 3.x 多模型 | 即梦图片系列 |
| 图生图，智能参考原图风格/内容进行编辑 | jimeng_i2i 3.0 |
| 局部重绘：涂抹修改或消除画面元素 | inpaint |
| 智能超清：低清图片放大到 4K / 8K | Seedream SR |
工具 | 能力 | 底层模型 |
| 文生视频，720P / 1080P / Pro 三档 | 即梦视频 3.0 |
| 图生视频：首帧、首尾帧、重新运镜、Pro 模式 | 即梦视频 3.0 |
| 动作模仿：将参考视频的动作迁移到目标人物 | DreamActor 2.0 |
| 数字人：图片 + 音频 → 口型同步说话视频 | OmniHuman 1.5 |
| 视频翻译：保留音色，口型同步换语言 | 翻译 2.0 |
内容创作者：对话式生成配图和视频素材，不切换工具
产品/设计：在 Cursor 里边改需求文档边生成原型图
营销团队：批量生成不同风格的创意图，描述即出图
开发者：在自己的 AI 应用中集成即梦能力，无需关心鉴权细节
登录火山引擎控制台，开通即梦 AI 服务
在访问控制 → API 访问密钥获取 Access Key ID 和 Secret Access Key
推荐使用 uvx（无需手动安装，运行时自动拉取）：
uvx jimeng-ai-mcp也可以用 pip 全局安装：
pip install jimeng-ai-mcp配置文件路径：
macOS：~/Library/Application Support/Claude/claude_desktop_config.json
Windows：%APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"jimeng": {
"command": "uvx",
"args": ["jimeng-ai-mcp"],
"env": {
"JIMENG_ACCESS_KEY_ID": "填入你的 Access Key ID",
"JIMENG_SECRET_ACCESS_KEY": "填入你的 Secret Access Key"
}
}
}
}配置文件路径：~/.cursor/mcp.json
{
"mcpServers": {
"jimeng": {
"command": "uvx",
"args": ["jimeng-ai-mcp"],
"env": {
"JIMENG_ACCESS_KEY_ID": "填入你的 Access Key ID",
"JIMENG_SECRET_ACCESS_KEY": "填入你的 Secret Access Key"
}
}
}
}重启客户端后，在对话框里直接输入指令即可，例如："帮我生成一张赛博朋克风格的城市夜景图"
git clone https://github.com/andyleimc-source/jimeng-ai-mcp
cd jimeng-mcp
cp .env.example .env
# 用编辑器打开 .env，填入两个密钥
uv sync
uv run jimeng-mcp本地调试（启动 MCP Inspector）：
uv run mcp dev src/jimeng_mcp/server.py以下是在 Claude Desktop 中的实际对话示例：
文生图
帮我生成一张宋代山水画风格的图片，16:9 横幅，用即梦 4.0 模型
图生图
把这张产品图的背景换成简洁的白色摄影棚风格，保留产品主体不变 [附上图片 URL]
文生视频
生成一段 10 秒的视频：一只狐狸在雪地里奔跑，慢镜头，电影感，16:9
图生视频（首尾帧）
我有两张图，帮我生成首尾帧驱动的视频，开头是这张日出照片，结尾是这张夕阳照片，5 秒 首帧：[URL1]，尾帧：[URL2]
数字人
用这张人物图片和这段音频，生成一个口型同步的数字人视频，输出 1080P 图片：[URL]，音频：[URL]
视频翻译
把这个中文视频翻译成英文，口型同步 [视频 URL]
generate_image参数 | 类型 | 默认值 | 说明 |
| string | 必填 | 图片描述 |
| string |
|
|
| string |
|
|
| string |
|
|
| string |
| 不希望出现的内容 |
generate_video参数 | 类型 | 默认值 | 说明 |
| string | 必填 | 视频描述 |
| string |
|
|
| string |
|
|
| int |
|
|
image_to_video参数 | 类型 | 默认值 | 说明 |
| string | 必填 | 首帧图片 URL |
| string | 必填 | 视频描述 |
| string |
|
|
| int |
|
|
| string |
| 尾帧图片（ |
translate_video参数 | 类型 | 默认值 | 说明 |
| string | 必填 | 原视频 URL |
| string | 必填 | 目标语言代码 |
| string |
| 源语言代码 |
语言代码：zh 中文 · en 英语 · ja 日语 · ko 韩语 · fr 法语 · de 德语 · es 西班牙语 · pt 葡萄牙语 · ru 俄语 · ar 阿拉伯语 · it 意大利语
变量 | 必填 | 说明 |
| ✅ | 火山引擎 Access Key ID |
| ✅ | 火山引擎 Secret Access Key |
| 可选 | 生成文件保存目录，默认 |
数字人生成（OmniHuman 1.5）：驱动人物图片口型和动作，配合音频生成说话视频。 使用模型：jimeng_realman_avatar_picture_omni_v15
portrait_url: 人物肖像图片 URL（含人物/动漫/宠物）
audio_url: 驱动音频 URL（WAV/MP3，必须小于 60 秒）
resolution: 输出分辨率，720 或 1080（默认 1080）
prompt: 可选提示词，支持中/英/日/韩语，最长 300 字符
注意：此接口使用 CVSubmitTask/CVGetResult（与普通接口不同）。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | ||
| audio_url | Yes | ||
| resolution | No | ||
| portrait_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full responsibility for behavioral disclosure. It adds valuable context such as the exact model, audio format and duration limits, resolution choices, prompt language constraints, and a warning that this API uses CVSubmitTask/CVGetResult rather than the normal interface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with bullet points for parameters and a clearly separated usage note. Every sentence provides useful information, 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 tool's purpose, all parameters, important constraints, and the non-standard API flow. Since an output schema is present, return values need not be explained, though it stops short of detailing how to actually use CVGetResult to retrieve results.
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%, but the description fully compensates by explaining all four parameters: portrait_url (person/anime/pet image), audio_url (WAV/MP3 under 60 seconds), resolution (720/1080 default 1080), and prompt (optional, multilingual, max 300 characters). This adds substantial 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?
The description clearly states that this tool generates a digital human talking video by driving a portrait image's lips and actions with audio, and it names the specific model (OmniHuman 1.5). This specific verb+resource combination distinguishes it from sibling tools like generate_video or image_to_video.
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 use case is implied by the phrase '数字人生成' (digital human generation) and the inputs described, but there is no explicit guidance on when to choose this tool over alternatives such as image_to_video or imitate_motion. No when-not-to-use or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
文生图：根据文字描述生成图片。
model（模型版本）：
jimeng_t2i_v40 图片生成 4.0（默认，推荐）
jimeng_seedream46_cvtob 图片生成 4.6（Seedream，支持最高 4K）
jimeng_t2i_v31 文生图 3.1
jimeng_t2i_v30 文生图 3.0
jimeng_high_aes_general_v21_L 通用高美感 v2.1
aspect_ratio: 1:1 / 16:9 / 9:16 / 4:3 / 3:4 / 3:2 / 2:3
quality: 2k（默认）/ normal
negative_prompt: 负面提示词（可选，部分模型不支持）
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | jimeng_t2i_v40 | |
| prompt | Yes | ||
| quality | No | 2k | |
| aspect_ratio | No | 1:1 | |
| negative_prompt | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds useful behavioral context: model versions with capabilities (e.g., 4.6 supports up to 4K), a default recommended model, and a caveat that negative_prompt is optional and may not be supported by all models. This goes beyond the schema, though it does not disclose rate limits, authentication, or async 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 one clear sentence followed by a concise bullet list of parameters. It is front-loaded with the purpose and avoids redundancy. Every line 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 5-parameter tool with rich model options, the description covers all parameters with defaults and options, and an output schema exists to describe return values. It lacks guidance on when to choose specific models beyond the default recommendation, but overall it is sufficiently complete for an image generation tool.
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 fully compensates. It enumerates valid model values with human-readable meanings, aspect ratio options, quality levels, and explains negative_prompt semantics including a support caveat. This adds substantial meaning beyond the bare input 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 '文生图：根据文字描述生成图片' (text-to-image: generate an image from a text description), using a specific verb and resource. It distinguishes itself from sibling tools like image_to_image and generate_video by explicitly framing itself as text-to-image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the 'text-to-image' framing: use this when you have a text description and want a generated image. However, there is no explicit when-not-to-use guidance or mention of alternative tools for related tasks (e.g., image_to_image for editing existing images).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
文生视频：根据文字描述生成视频（约需 1～5 分钟）。
model（模型版本）：
jimeng_t2v_v30 视频生成 3.0 720P（默认）
jimeng_t2v_v30_1080p 视频生成 3.0 1080P
jimeng_ti2v_v30_pro 视频生成 3.0 Pro 1080P（效果更好）
aspect_ratio: 16:9 / 4:3 / 1:1 / 3:4 / 9:16 / 21:9
duration_sec: 5（默认）或 10
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | jimeng_t2v_v30 | |
| prompt | Yes | ||
| aspect_ratio | No | 16:9 | |
| duration_sec | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides useful behavioral context such as the approximate generation time (1–5 minutes) and model quality differences. However, it does not disclose asynchronous behavior, rate limits, or potential error conditions.
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 compact and front-loaded: a one-sentence purpose followed by a bulleted parameter list. Every line adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool's scope, the description covers key operational details: models, aspect ratios, duration, and time estimate. Minor omissions like prompt length limits or content restrictions leave small 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 no descriptions, but the description fully compensates by enumerating valid model options, aspect ratios, and duration choices (5 or 10 seconds). It adds significant 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?
The description clearly states the tool generates video from text (文生视频：根据文字描述生成视频), using a specific verb and resource. This distinguishes it from sibling tools like image_to_video and image_to_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear that this tool is for text-to-video generation, providing a clear context for when to use it. It does not explicitly exclude alternatives, but the input criterion (text description) is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
图生图（智能参考）：参考输入图片，结合文字描述编辑或生成新图片。 使用即梦图生图 3.0 模型（jimeng_i2i_v30）。
image_url: 参考图片 URL（JPEG/PNG，最大 4.7MB，最大 4096×4096）
aspect_ratio: 1:1 / 16:9 / 9:16 / 4:3 / 3:4 / 3:2 / 2:3
quality: 2k（默认）/ normal
scale: 文本影响程度 0.0～1.0（默认 0.5，越大越贴近文字描述，越小越保留原图）
| Name | Required | Description | Default |
|---|---|---|---|
| scale | No | ||
| prompt | Yes | ||
| quality | No | 2k | |
| image_url | Yes | ||
| aspect_ratio | No | 1:1 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 compensates well by disclosing model choice, image format/size limits (JPEG/PNG, max 4.7MB, 4096×4096), aspect ratio options, quality settings, and the semantics of the 'scale' parameter. It does not describe output formatting, but an output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It opens with a clear purpose statement, then provides a compact bulleted list of parameter details. Every sentence adds value, and there is no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with 5 parameters, and the description covers most of them thoroughly. It includes model version and input constraints. It does not explicitly differentiate from sibling tools (like inpaint_image), and the 'prompt' parameter could use a bit more elaboration, but overall it is sufficient for an agent to confidently invoke the tool.
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 provides only type/defaults with no property descriptions (0% schema description coverage), so the description must add meaning. It explains image_url constraints, allowed aspect ratios, quality choices (2k default vs normal), and scale's effect (0.0-1.0, larger follows text, smaller preserves the original). The 'prompt' parameter is implicitly covered via '结合文字描述' but lacks explicit format details.
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: '图生图（智能参考）：参考输入图片，结合文字描述编辑或生成新图片' (image-to-image with smart reference: edit or generate new images based on an input image and text description). It also specifies the underlying model (jimeng_i2i_v30), making the purpose specific and distinct from siblings like generate_image or inpaint_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by emphasizing '参考输入图片' (reference input image) and '结合文字描述' (combined with text description), suggesting it is for image-conditioned generation. However, it does not explicitly state when to prefer this tool over alternatives such as inpaint_image or generate_image, nor does it provide exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
图生视频：将静态图片转换为动态视频（约需 1～5 分钟）。
image_url: 首帧图片 URL（JPEG/PNG，最大 4.7MB）
prompt: 视频内容描述（必填）
mode（模式）：
first 首帧驱动 720P（默认）
first_1080p 首帧驱动 1080P
first_tail 首尾帧驱动 720P（需提供 tail_image_url）
first_tail_1080p 首尾帧驱动 1080P（需提供 tail_image_url）
recamera 重新运镜 720P（需提供 template_id，通过 prompt 描述运镜效果）
pro 视频生成 3.0 Pro 1080P（首帧，效果更好）
duration_sec: 5（默认）或 10
tail_image_url: 尾帧图片 URL（仅 first_tail / first_tail_1080p 模式需要）
recamera 模式可用运镜模板（在 prompt 中指定 template_id）： hitchcock_dolly_in / hitchcock_dolly_out / robo_arm / dynamic_orbit / central_orbit / crane_push / quick_pull_back / counterclockwise_swivel / clockwise_swivel / handheld / rapid_push_pull
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | first | |
| prompt | Yes | ||
| image_url | Yes | ||
| duration_sec | No | ||
| tail_image_url | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral transparency burden. It does so admirably by disclosing an estimated duration ('约需 1～5 分钟'), image constraints (JPEG/PNG, max 4.7MB), mode resolutions (720P/1080P), and conditional requirements for tail_image_url and template_id. It stops short of explaining the async nature or result retrieval, but the output schema may cover that.
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-organized with a clear one-sentence purpose, followed by structured bullet points for each parameter and mode. It is slightly long but every line adds operational value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters and multiple modes, the description is remarkably complete. It covers all input constraints, mode-specific behaviors, duration options, and even provides sub-list of template IDs. Since an output schema exists, not describing return values is acceptable. The only minor omission is an explicit statement about whether the operation is synchronous, but the time estimate strongly implies asynchronous.
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 does so fully by explaining every parameter: image_url's format and size, prompt as required, mode's enumerated values with meanings, duration_sec allowed values, and tail_image_url's conditional use. It even lists specific recamera template IDs, going far 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?
The description opens with '图生视频：将静态图片转换为动态视频', which clearly states the tool's purpose: converting a static image into a dynamic video. This is a specific verb+resource combination that distinguishes it from sibling tools like generate_video (likely text-to-video) and image_to_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description details the various modes and their prerequisites (e.g., first_tail requires tail_image_url, recamera requires template_id), giving implicit usage context. However, it never explicitly states when to choose this tool over alternatives like generate_video or image_to_image, lacking a direct comparison or exclusion note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
动作模仿 2.0：提取参考视频中的动作/表情/口型，迁移到目标人物图片上。 使用模型：jimeng_dreamactor_m20_gen_video
image_url: 目标人物图片 URL（JPEG/PNG，480×480 以上，1920×1080 以内）
video_url: 动作参考视频 URL（MP4/MOV/WEBM，最长 30 秒）
输出视频约需 3～5 分钟（10 秒视频约需 180 秒）。
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | ||
| video_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses a notable behavioral trait: '输出视频约需 3～5 分钟（10 秒视频约需 180 秒）' (output video takes approximately 3–5 minutes), indicating this is a long-running operation. It also specifies input format and size limits, which inform the agent of constraints. However, it does not mention side effects, authentication, or whether the operation is asynchronous, though output schema likely covers return details.
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 compact and front-loaded with the purpose, followed by model name, parameter details in a bullet-like format, and latency estimate. Each sentence adds value with no redundancy. It is appropriately sized for a moderately complex 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?
Given the tool complexity (video generation with two inputs), the description covers purpose, inputs, constraints, and expected latency. It does not explicitly mention prerequisites like whether the image must contain a person's face or the video must contain human motion, but these are implied by '目标人物图片' and '动作参考视频'. Output schema likely handles return format, so this description is sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does: 'image_url: 目标人物图片 URL（JPEG/PNG，480×480 以上，1920×1080 以内）' and 'video_url: 动作参考视频 URL（MP4/MOV/WEBM，最长 30 秒）' provide semantics, formats, and constraints. This fully compensates for 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?
The description clearly states the tool's function: '动作模仿 2.0：提取参考视频中的动作/表情/口型，迁移到目标人物图片上' (extract actions/expressions/lip sync from a reference video and transfer to a target person image). This specific verb+resource pairing distinguishes it from siblings like image_to_video or generate_digital_human by focusing on motion transfer from a video to a person image. It also names the model, reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: the tool is used when you have a reference video and a target person image, and it lists the required inputs (image_url, video_url) with constraints (formats, sizes, max duration). It does not explicitly list when to avoid using it or name alternatives, but the usage scenario is evident from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
局部重绘（Inpainting）：在图片的指定区域（mask）内根据提示词重新生成内容。 使用即梦交互编辑模型（jimeng_image2image_dream_inpaint）。
image_url: 原图 URL（JPEG/PNG，最大 4.7MB）
mask_url: 遮罩图 URL（单通道灰度图，白色=重绘区域，黑色=保留区域）
prompt: 重绘内容描述；输入"删除"可消除选区内容
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| mask_url | Yes | ||
| image_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 adds useful context by specifying the model (jimeng_image2image_dream_inpaint), the mask encoding (white=redraw, black=preserve), and special prompt behavior ('删除' to erase). However, it does not discuss side effects, reversibility, or auth requirements, which are less critical for an image editing tool but still would enhance transparency.
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 compact and front-loaded with a clear summary sentence, followed by a concise bulleted list for parameters. Every sentence earns its place, with no filler or redundancy. It is structured for quick parsing by an agent.
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 relatively simple tool, the description covers the core behavior and input requirements thoroughly. It does not need to describe return values because an output schema exists. Minor gaps include lack of mention of output format and no explicit alternative distinction, but overall the description is nearly complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema offers only parameter names and types, with 0% coverage. The description compensates fully by detailing allowed formats (JPEG/PNG), size limit (4.7MB), mask semantics (single-channel grayscale, white/black meanings), and special prompt usage. This transforms bare schema into actionable 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 clearly states the tool's purpose: local inpainting (局部重绘) that regenerates content in a masked region based on a prompt. It is specific and distinct from generic image generation, but it does not explicitly differentiate itself from the sibling tool 'image_to_image', missing the opportunity to highlight the mask-based uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It neither mentions scenarios where inpainting is appropriate nor contrasts with siblings like image_to_image or generate_image. The usage context is only implied by the parameter semantics (mask), but no explicit or even implicit 'use when' or 'avoid when' statements are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
视频翻译 2.0：将视频中的语音翻译并口型同步为目标语言。 使用模型：video_translate_v2_cvtob
video_url: 原始视频 URL（需公网可访问）
target_language: 目标语言缩写
src_language: 源语言缩写（默认 "zh" 中文）
支持的语言代码： zh（中文）en（英语）ja（日语）ko（韩语）fr（法语）de（德语） es（西班牙语）pt（葡萄牙语）ru（俄语）ar（阿拉伯语）it（意大利语） hi（印地语）id（印尼语）nl（荷兰语）tr（土耳其语）pl（波兰语）等
| Name | Required | Description | Default |
|---|---|---|---|
| video_url | Yes | ||
| src_language | No | zh | |
| target_language | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 behavioral traits. It mentions the model used and the public URL requirement, but does not disclose whether the operation is asynchronous, how the result is returned, potential costs/latency, or any side effects. For a complex video processing tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a clear purpose statement, then uses bullet points for parameters and a compact list for languages. The language list is necessary but adds length; overall it's well-structured and not wasteful.
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 tool is complex (video translation with lip sync), and the description covers inputs, model, and language support. However, it omits operational details like output format, processing time, video size limits, or error conditions. Since an output schema exists, return value explanation is less critical, but other contextual gaps remain.
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 explain parameters. It does so effectively: video_url must be publicly accessible, target_language is an abbreviation, and src_language defaults to "zh". It also provides a list of supported language codes. This adds 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?
The description clearly states the tool's specific function: translating speech in a video into a target language while syncing lip movements. This specific verb+resource (translate video + sync lips) distinguishes it from sibling tools like generate_video or image_to_video, which create new content rather than transform existing speech.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: requires a publicly accessible video URL and target language, with an optional source language. It also lists supported language codes. However, it does not explicitly mention when to prefer this tool over alternatives or when not to use it. This is close to 'clear context, no exclusions' but lacks explicit alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
智能超清：将图片放大并增强细节至 4K 或 8K 分辨率。 使用即梦智能超清模型（jimeng_i2i_seed3_tilesr_cvtob）。
image_url: 输入图片 URL（JPEG/PNG，最大 4.7MB，最大 4096×4096）
resolution: "4k"（默认）或 "8k"
detail: 细节生成程度 0～100（默认 50，越大细节越多但可能偏离原图）
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | ||
| image_url | Yes | ||
| resolution | No | 4k |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the underlying model, input constraints, and a key side effect (higher detail may deviate from the original). It lacks info on postconditions like whether the original is modified, but the output schema covers return format.
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 compact and front-loaded with the main purpose, followed by a succinct parameter breakdown. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all three parameters with defaults and constraints, includes behavioral context, and benefits from an output schema. It is complete for a straightforward tool, despite not explicitly naming alternatives.
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 fully compensates by explaining each parameter's type, default, allowed values, and constraints (e.g., image_url format/size, resolution choices, detail range and trade-off).
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: enlarging and enhancing image detail to 4K/8K resolution. The specific model name and parameter list further clarify its role, distinguishing it from sibling generation tools like generate_image or image_to_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (whenever image upscaling to 4K/8K is needed). It does not explicitly compare to alternatives, but the purpose is unambiguous enough for an agent to select this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0generate_digital_humangenerate_imagegenerate_videoimage_to_imageimage_to_videoimitate_motioninpaint_imagetranslate_videoupscale_imageScored across 9 tools
Each tool targets a distinct media generation or editing task: text-to-image, image-to-image, inpainting, upscaling, text-to-video, image-to-video, motion imitation, digital human creation, and video translation. There is no meaningful overlap between these operations.
All tool names use a consistent lowercase_snake_case convention with a clear verb_noun or transformation pattern (generate_image, inpaint_image, image_to_video, translate_video). The two image_to_* names follow a predictable transformation pattern, making the set uniform and intuitive.
With 9 tools, the server is well-scoped for an AI media generation platform. Each tool covers a distinct capability without redundancy, and the count falls comfortably within the ideal 3-15 range.
The tool surface covers the core media generation lifecycle: image creation/editing/upscaling, video generation from text or images, motion transfer, digital humans, and video translation. Minor gaps like audio generation or task management are not critical for the stated purpose, but the set is quite comprehensive.
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation
Create images and videos from prompts, with options for image mixing, reference images, and start/…
Create AI images and videos, manage projects and credits, and use workspace campaign context.
Generate images, video, and audio with Glif's media-generation agent
