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-video-mcp-server Generate a 5-second video from this image of a sunset with clouds moving."
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.
一个用于在 Cursor 中调用即梦视频 3.0 图生视频（首帧）API 的 MCP 服务器。
图生视频（首帧模式）: 提供一张首帧图片 + 文字描述，生成 720P 视频
5s / 10s 时长: 支持 121 帧（5秒）或 241 帧（10秒）
中英文 Prompt: 支持中英文混合描述
可复现: 通过 seed 参数可复现相同视频
Related MCP server: Jimeng MCP Server
cd jimeng-video-mcp-server
npm install
npm run build如果在国内使用时遇到 SSL 证书错误、安装缓慢或连接超时问题，请使用以下命令：
cd jimeng-video-mcp-server
npm install --registry=https://registry.npmmirror.com --verbose --unsafe-perm --strict-ssl=false
npm run build在 Cursor 的 MCP 设置中（Settings → MCP → Add new MCP server）添加：
{
"mcpServers": {
"jimeng-video": {
"command": "node",
"args": ["/你的绝对路径/jimeng-video-mcp-server/dist/index.js"],
"env": {
"VOLC_ACCESS_KEY_ID": "你的AccessKeyID",
"VOLC_SECRET_ACCESS_KEY": "你的SecretAccessKey",
"NODE_TLS_REJECT_UNAUTHORIZED": "0"
}
}
}
}⚠️ 将路径替换为实际路径。
NODE_TLS_REJECT_UNAUTHORIZED仅在有代理/VPN 时需要。
jimeng_generate_video提交视频生成任务，返回 task_id。需要手动查询结果。
jimeng_query_video_task根据 task_id 查询任务状态和结果。
jimeng_generate_video_and_wait ⭐ 推荐一站式工具：提交任务并自动轮询等待结果（最多 5 分钟），直接返回视频 URL。
在 Cursor 中直接对话：
"用这张图生成一段 5 秒的视频，镜头缓缓拉远" + 提供图片 URL
"Generate a 10s video from this image with camera slowly panning left"
"把这张风景照变成视频，加上飘落的树叶效果"
参数 | 说明 |
| 视频运动/内容描述，中英文均可，建议 400 字以内 |
| 首帧图片 URL（JPEG/PNG，最大 4.7MB） |
| 首帧图片 base64（与 image_url 二选一） |
| 帧数：121 = 5秒，241 = 10秒（默认 121） |
| 随机种子，-1 为随机（默认 -1） |
格式：JPEG 或 PNG
文件大小：最大 4.7MB
分辨率：最大 4096×4096，最短边不低于 320px
宽高比：长边与短边比例在 3 以内
⏱️ 视频生成较慢，通常需要 1-3 分钟
🔗 视频 URL 有效期仅 1 小时，请及时下载
🎬 输出为 720P 分辨率视频
与图片 MCP 相同，可运行诊断工具：
VOLC_ACCESS_KEY_ID=你的AK VOLC_SECRET_ACCESS_KEY=你的SK npm run test-connectionSubmit a video generation task using Jimeng Video 3.0 (即梦视频3.0).
This is an image-to-video (first frame) model. You provide:
A first-frame image (URL or base64) as the starting visual
A text prompt describing the desired motion/action
Output: 720P video, either 5 seconds (121 frames) or 10 seconds (241 frames).
Args:
prompt (string, required): Text description of desired video motion/content. Chinese or English. Max ~800 chars.
image_url (string, optional): URL of the first-frame image. JPEG/PNG, max 4.7MB, max 4096x4096, min short side 320px, aspect ratio within 3:1.
image_base64 (string, optional): Base64-encoded first-frame image. Same constraints as image_url.
frames (number, optional): Total frames. 121 = 5 seconds, 241 = 10 seconds. Default: 121 (5s).
seed (number, optional): Random seed for reproducibility. Default: -1 (random).
Note: Either image_url or image_base64 must be provided (one of the two).
Returns: task_id for querying results with jimeng_query_video_task.
Examples:
prompt="镜头缓缓拉远，花瓣随风飘落" + image_url="https://..." -> 5s video
prompt="The camera slowly zooms out as petals fall" + image_url="https://..." + frames=241 -> 10s video
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Random seed. -1 for random. Same seed + same params = same result. | |
| frames | No | Total frames: 121 for 5s video, 241 for 10s video. Default: 121. | |
| prompt | Yes | Video generation prompt. Chinese or English. Max 800 chars. | |
| image_url | No | First-frame image URL. JPEG/PNG, max 4.7MB, max 4096x4096. | |
| image_base64 | No | First-frame image as base64 string. Alternative to image_url. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations flag openWorldHint and non-idempotent write behavior, and the description adds substantial context beyond them: it is an asynchronous submit (returns task_id), it requires a first-frame image, output is 720P at 5s/10s, and the constraint that either image_url or image_base64 must be supplied. This is rich disclosure relative to what the structured fields already carry.
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 the model identity and input/output summary, then a clean Args list, a note, and two bilingual examples that earn their place. There is minor duplication of image constraints between the description and the schema, but overall it is well-organized rather than padded.
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 output schema, the description carries the return burden and does so ('Returns: task_id'), and it covers the required alternate image inputs, output format, and the query follow-up. Nothing an agent needs to invoke it correctly is missing.
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, but the description adds meaning: it maps frames values to seconds (121=5s, 241=10s), notes the seed default of -1 for reproducibility, and crucially states 'Either image_url or image_base64 must be provided (one of the two)' – a constraint the schema does not express since only prompt is marked required.
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+resource ('Submit a video generation task') plus the model (Jimeng Video 3.0) and clarifies it is an image-to-video first-frame model. It routes the agent to the sibling that retrieves results ('task_id for querying results with jimeng_query_video_task'), so the agent can distinguish it from its query counterpart without opening the schema.
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 workflow context is clear: submit here, then poll with jimeng_query_video_task, and the input requirements (first-frame image + motion prompt) tell the agent when this applies. However, it never contrasts the async submit against the sibling jimeng_generate_video_and_wait, leaving the agent to infer when to wait instead of polling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a video using Jimeng Video 3.0 and automatically poll until complete.
Convenience tool that combines jimeng_generate_video + jimeng_query_video_task. Submits the task and polls for the result, returning the video URL when done.
All parameters are the same as jimeng_generate_video. Timeout: ~5 minutes (video generation is slower than image generation). Polling interval: 10 seconds.
Args:
prompt (string, required): Video motion/content description (Chinese or English, max 800 chars)
image_url (string, optional): First-frame image URL (JPEG/PNG)
image_base64 (string, optional): First-frame image as base64
frames (number, optional): 121 for 5s, 241 for 10s. Default: 121
seed (number, optional): Random seed. Default: -1
Note: Either image_url or image_base64 is required.
Returns: Video URL (valid 1 hour) or error message.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Random seed | |
| frames | No | 121 for 5s, 241 for 10s | |
| prompt | Yes | Video generation prompt | |
| image_url | No | First-frame image URL | |
| image_base64 | No | First-frame image base64 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare non-readonly, non-idempotent, open-world, non-destructive. The description adds genuinely useful behavior beyond that: the ~5 minute timeout, the 10-second polling interval, and critically the 1-hour URL validity. It does not say what happens on timeout beyond 'error message', which 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?
Front-loaded purpose sentence, then composition, then behavior (timeout/interval), then args, then returns. Every line earns its place; 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?
Covers the wrapper relationship, polling behavior, timing, return value and URL expiry, and the cross-field requirement. For a blocking convenience tool with no output schema this is nearly complete; only timeout-failure handling is left implicit.
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 baseline is 3. The description adds value by stating the frames mapping (121 for 5s, 241 for 10s) and the prompt's language/char limit, plus the crucial constraint 'Either image_url or image_base64 is required' – a cross-parameter rule JSON Schema cannot express.
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 precise verb+resource ('Generate a video using Jimeng Video 3.0') and immediately explains this is a wrapper that combines the two named siblings. An agent can distinguish it from jimeng_generate_video and jimeng_query_video_task without opening any schema.
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?
Explicitly names both sibling tools it composes and describes the convenience-tool use case: submit-and-poll in one call. The timeout context ('video generation is slower than image generation') further signals when this synchronous wrapper is appropriate versus the async pair.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the status and result of a Jimeng Video 3.0 generation task.
Use after calling jimeng_generate_video to get the generated video. Video generation typically takes 1-3 minutes. If status is "in_queue" or "generating", wait and query again.
Args:
task_id (string, required): The task ID returned by jimeng_generate_video.
Returns:
status: in_queue | generating | done | not_found | expired
video_url: Generated video URL (when done, valid for 1 hour only!)
Important: Video URLs expire after 1 hour. Download promptly.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task ID from jimeng_generate_video |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the safe read-only/idempotent profile, and the description adds substantial behavior beyond them: expected generation latency of 1-3 minutes, the full status enumeration, polling guidance, and critically the 1-hour expiry of the returned video URL. This is exactly the extra operational context annotations cannot express.
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 purpose, then structured Args/Returns/polling guidance. Slightly redundant in stating the 1-hour URL expiry twice (in Returns and the closing Important line), but every block carries useful 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?
With no output schema, the description takes on the burden of documenting return values and does so fully: status values, video_url presence condition, and expiry. Latency expectation and polling behavior round out what an agent needs to call and use 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 100% for the single task_id parameter, so the baseline is 3; the description adds provenance by stating the ID is what jimeng_generate_video returned, which helps the agent source the value correctly.
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 (query) and resource (status and result of a Jimeng Video 3.0 task), and explicitly ties itself to the sibling tool jimeng_generate_video as its prerequisite, so an agent can distinguish it from the generation tools without opening the schema.
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?
"Use after calling jimeng_generate_video" gives clear triggering context, and the polling advice for in_queue/generating statuses tells the agent how to act on results. It does not mention jimeng_generate_video_and_wait as the blocking alternative, which would be the natural way to avoid polling entirely.
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.
v1.0.0jimeng_generate_videojimeng_generate_video_and_waitjimeng_query_video_taskScored across 3 tools
The three tools have clear boundaries: submit, query, and a combined submit-and-wait convenience tool. The only ambiguity is jimeng_generate_video_and_wait overlapping with the explicit two-step flow, but the description clearly frames it as a convenience wrapper.
All tools follow a consistent jimeng_<verb>_<noun> snake_case pattern (jimeng_generate_video, jimeng_query_video_task, jimeng_generate_video_and_wait), and the query verb matches its task_id return/argument naming.
Three tools is slightly thin but justified for an async generation service: submit, query, and a synchronous convenience variant. It covers the essential workflow without bloat.
The full generate→poll lifecycle is covered, including a blocking convenience variant. Minor gaps: no cancellation, task listing, or asset/upload handling, but the domain (image-to-video generation) is otherwise well-served.
Create images and videos from prompts, with options for image mixing, reference images, and start/…
Generate images, videos, voiceovers, and captions from a chat prompt.
Create and manage AI image and video generations through Quriov's fixed public MCP tools.
Create and manage cinematic AI video renders through the Future Video Studio Agent API.
