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-web-mcp 生成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.
基于TypeScript的Model Context Protocol (MCP) 服务器，直接访问即梦AI Web端
🚀 直接访问Web端 | 每日免费积分 | 最新功能支持 | 组合模式架构 | 100%类型安全
English | 中文
本项目仅供学习和研究使用，请勿用于商业或其他用途。
本项目通过技术手段访问即梦AI Web端接口
使用本项目需遵守即梦AI的服务条款
因使用本项目产生的任何问题，开发者不承担责任
建议仅在学习研究场景下使用，不要滥用API接口
Related MCP server: Jimeng AI Multimodal MCP
智能继续生成 - prompt自动识别数量（如"生成9张图片"），一次返回全部结果
系列图生成 - 专用于高相关性场景：房间系列、故事分镜、产品多角度
多参考图混合 - 支持最多4张参考图，可控制每张强度
同步/异步模式 - 灵活选择即时返回或后台生成
纯文本生成 - 从prompt直接创建视频
首尾帧控制 - 精确控制视频起止画面
多帧动画 - 2-10个关键帧，系统自动补间平滑过渡
主体融合 - 将多张图片的主体组合到一个场景（使用[图0]语法）
每日免费积分 - 每天可获得60-80免费积分，无需付费
最新功能支持 - 直接访问Web端，第一时间体验新功能
无需API密钥 - 只需登录账号获取sessionid即可使用
组合模式设计 - 74.6%代码减少（5,268行 → 1,335行）
零安装部署 - npx自动安装，无需手动配置
TypeScript + Zod - 完整类型定义和运行时验证
100%向后兼容 - 无缝升级，现有代码无需修改
访问 即梦AI官网 并登录
按 F12 打开开发者工具
进入 Application > Cookies
复制 sessionid 的值
编辑Claude Desktop配置文件：
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
添加以下配置：
{
"mcpServers": {
"jimeng-web-mcp": {
"command": "npx",
"args": ["-y", "jimeng-web-mcp"],
"env": {
"JIMENG_API_TOKEN": "你的sessionid"
}
}
}
}配置完成！现在可以在Claude中使用即梦AI生成功能。
工具 | 默认模式 | 适用场景 | 说明 |
| 同步 | 单图/智能多图生成 | prompt自动识别数量，如"生成9张图片" |
| 异步 | 高相关性系列图 | 房间系列、故事分镜、产品多角度 |
工具 | 默认模式 | 适用场景 | 说明 |
| 异步 | 纯文本生成视频 | 从prompt直接创建 |
| 异步 | 首尾帧控制 | 支持首帧、尾帧或两者 |
| 异步 | 多帧动画 | 2-10个关键帧，系统补间 |
| 异步 | 主体融合 | 用 |
工具 | 说明 |
| 查询单个任务状态和结果 |
| 批量查询最多10个任务 |
| 测试服务器连接 |
工具 | 说明 |
| 帧插值、超分辨率、音效生成（开发中） |
image - 单图/智能多图生成✅ 智能数量识别 - prompt中的"生成N张图片"会被自动识别
✅ 继续生成自动触发 - 当N>4时，完成前4张后自动确认继续
✅ 一次性返回 - 等待所有图片完成，统一返回结果
✅ 多参考图支持 - 最多4张参考图，可单独控制强度
参数 | 类型 | 必填 | 默认值 | 说明 |
| string | ✅ | - | 图片描述，可包含数量（如"生成9张图片"） |
| string[] | ❌ | - | 参考图路径数组（最多4张） |
| string | ❌ | jimeng-4.0 | 模型名称 |
| string | ❌ | auto | 宽高比：auto/1:1/16:9/9:16/3:4/4:3/3:2/2:3/21:9 |
| number | ❌ | 0.5 | 参考图影响强度 (0-1) |
| number[] | ❌ | - | 每张参考图独立强度 |
| string | ❌ | - | 负面提示词 |
| boolean | ❌ | false | 是否异步模式 |
示例1: 智能继续生成
// Claude中直接说：
"请用image工具生成9张不同角度的可爱橘猫图片"
// 工具调用：
{
"prompt": "帮我生成9张图片，可爱的橘猫，分别是：正面、侧面、背面、俯视、仰视、左卧、右玩、奔跑、睡觉",
"model": "jimeng-4.0",
"async": false
}
// 结果：一次性返回9张图片URL ✅示例2: 多参考图混合
{
"prompt": "梵高星空风格的城市夜景",
"filePath": [
"/path/to/starry-night.jpg",
"/path/to/city.jpg"
],
"reference_strength": [0.7, 0.3],
"async": false
}工作原理：
API根据prompt识别总数量（如"生成9张" → totalCount=9）
先生成前4张图片
完成第4张时暂停，等待确认
系统自动发送action=2确认
API继续生成剩余5张图片
返回全部9张结果
重要特性：
✅ 单次确认：只发送一次继续请求，不是循环生成
✅ 智能识别：从prompt自动解析数量，无需count参数
✅ 完整等待：同步模式会等待所有图片完成
image_batch - 系列图生成✅ 推荐使用场景：
同一房子的不同空间（客厅、卧室、厨房、书房）
故事连续分镜（场景1、场景2、场景3）
绘本不同页面（第1页、第2页、第3页）
产品多角度展示（正面、侧面、背面、细节）
❌ 不适用场景：
完全无关的独立图片
单张图片生成（请用image）
参数 | 类型 | 必填 | 默认值 | 说明 |
| string[] | ✅ | - | 每张图的差异描述（1-15个） |
| string | ❌ | - | 整体通用描述，添加在最前面 |
| string[] | ❌ | - | 可选参考图（影响整体风格） |
| string | ❌ | jimeng-4.0 | 模型名称 |
| string | ❌ | auto | 宽高比 |
| number | ❌ | 0.5 | 参考图强度 |
| boolean | ❌ | true | 是否异步模式 |
示例1: 房间系列
{
"basePrompt": "三室两厅现代简约风格，木地板，暖色调照明，简约家具",
"prompts": [
"客厅，灰色布艺沙发靠窗，落地窗洒入阳光，茶几上放着杂志和遥控器",
"主卧室，米色床品整齐铺展，木质床头柜上有台灯，墙面淡蓝色乳胶漆",
"开放式厨房，白色橱柜整齐排列，大理石台面，中岛台上摆放水果篮",
"书房，木质书架靠墙摆放，书桌上有笔记本电脑，窗外绿植清晰可见",
"儿童房，彩色玩具收纳柜，小床上铺着卡通床品，墙上贴着儿童画"
],
"async": true
}
// 最终prompt格式：
// "三室两厅现代简约风格，木地板，暖色调照明，简约家具 第1张：客厅... 第2张：主卧室... 一共5张图"示例2: 产品多角度
{
"basePrompt": "苹果AirPods Pro 2代，白色陶瓷材质，磨砂质感，苹果logo清晰",
"prompts": [
"正面特写，充电盒开盖状态，耳机在盒内，LED指示灯可见",
"侧面45度角，展示充电盒厚度和圆润边缘，耳机柄部分露出",
"背面视角，充电口特写，序列号区域清晰，磁吸接触点可见"
],
"async": false
}⚠️ 错误示例：
// ❌ prompts过于简短，缺少差异描述
{
"prompts": ["客厅", "卧室", "厨房"] // 太简单！
}
// ✅ 正确做法：每个prompt应该是一小段话
{
"prompts": [
"客厅，灰色沙发靠窗，阳光洒入...",
"卧室，米色床品，木质床头柜...",
"厨房，白色橱柜，大理石台面..."
]
}video - 纯文本生成视频参数 | 类型 | 必填 | 默认值 | 说明 |
| string | ✅ | - | 视频描述 |
| string | ❌ | jimeng-video-3.0 | 视频模型 |
| string | ❌ | 720p | 分辨率：720p/1080p |
| number | ❌ | 24 | 帧率 (12-30) |
| number | ❌ | 5000 | 时长（毫秒，3000-15000） |
| string | ❌ | 16:9 | 宽高比 |
| boolean | ❌ | true | 是否异步 |
{
"prompt": "一只小狗在草地上奔跑，阳光明媚，镜头跟随，高清画质",
"resolution": "1080p",
"fps": 30,
"duration": 5000,
"async": true
}video_frame - 首尾帧控制参数 | 类型 | 必填 | 默认值 | 说明 |
| string | ✅ | - | 视频描述 |
| string | ❌ | - | 首帧图片路径 |
| string | ❌ | - | 尾帧图片路径 |
其他参数 | - | - | - | 同 |
{
"prompt": "从白天到夜晚的城市延时摄影",
"firstFrameImage": "/path/to/day.jpg",
"lastFrameImage": "/path/to/night.jpg",
"resolution": "1080p",
"async": true
}video_multi - 多帧动画关键帧过渡动画：提供2-10个关键帧图片，系统在帧间生成平滑过渡。
⚠️ 重要：每帧的prompt描述的是"从当前帧到下一帧的过渡过程"，包括：
镜头移动：推进、拉远、摇移、跟随
画面变化：主体动作、场景变化、光影变化
转场效果：淡入淡出、切换方式
最后一帧的prompt不生效（因为没有下一帧），可以留空或随意填写。
参数 | 类型 | 必填 | 说明 |
| Frame[] | ✅ | 关键帧数组（2-10个） |
| number | ✅ | 帧序号（从0开始） |
| string | ✅ | 帧图片绝对路径 |
| number | ✅ | 过渡时长（1000-6000毫秒） |
| string | ✅ | 过渡过程描述 |
其他参数 | - | - | 同 |
{
"frames": [
{
"idx": 0,
"imagePath": "/path/frame0.jpg",
"duration_ms": 2000,
"prompt": "镜头从正面缓慢推进，猫从坐姿站起，光线从左侧照入"
},
{
"idx": 1,
"imagePath": "/path/frame1.jpg",
"duration_ms": 2000,
"prompt": "猫向前迈步行走，尾巴自然摇摆，背景虚化效果增强"
},
{
"idx": 2,
"imagePath": "/path/frame2.jpg",
"duration_ms": 1000,
"prompt": "（最后一帧，此prompt不生效）"
}
],
"fps": 24,
"resolution": "720p",
"async": true
}
// 生成效果（总时长5秒）：
// 0-2秒：显示frame0 + 执行"站起来"动画 → 渐变到frame1
// 2-4秒：显示frame1 + 执行"行走"动画 → 渐变到frame2
// 4-5秒：显示frame2作为结尾画面video_mix - 主体融合将多张图片的主体组合到一个场景中，使用[图0]、[图1]语法引用。
参数 | 类型 | 必填 | 说明 |
| string[] | ✅ | 参考图路径数组（2-4张） |
| string | ✅ | 必须包含 |
其他参数 | - | - | 同 |
示例1: 角色换场景
{
"referenceImages": [
"/path/cat.jpg",
"/path/floor.jpg"
],
"prompt": "[图0]中的猫在[图1]的地板上奔跑",
"async": true
}示例2: 多元素组合
{
"referenceImages": [
"/path/person.jpg",
"/path/car.jpg",
"/path/beach.jpg"
],
"prompt": "[图0]中的人坐在[图1]的车里，背景是[图2]的海滩日落景色",
"resolution": "1080p",
"async": true
}query - 查询单个任务{
"historyId": "4761818115596"
}
// 返回：
{
"status": "completed",
"progress": 100,
"imageUrls": ["https://...", "https://...", ...]
}query_batch - 批量查询{
"historyIds": [
"4761818115596",
"4761818115597",
"1e06b3c9-bd41-46dd-8889-70f2c61f66bb" // 视频ID
]
}
// 返回：
{
"4761818115596": { "status": "completed", "imageUrls": [...] },
"4761818115597": { "status": "processing", "progress": 45 },
"1e06b3c9-...": { "status": "completed", "videoUrl": "https://..." }
}# 使用npm
npm install
# 或使用yarn
yarn install# 开发模式（热重载）
npm run dev
# 类型检查
npm run type-check
# 构建项目
npm run build
# 运行测试
npm test
# 测试覆盖率
npm run test:coverage
# 测试MCP服务器
npm run test:mcp# MCP stdio模式
npm start
# HTTP API服务模式
npm run start:api检查清单：
✅ JIMENG_API_TOKEN是否正确配置
✅ 即梦账号积分是否充足（登录查看）
✅ 提示词是否包含敏感内容
✅ 参考图路径是否有效（网络图需可公开访问）
排查步骤：
✅ prompt中是否明确指定数量（如"生成9张图片"）
✅ 查看API返回的totalCount是否正确识别
✅ 检查是否在同步模式下（async: false）
✅ 查看日志中的[智能继续生成检测]信息
解决方法：
✅ 确保Node.js版本 ≥ 16.0
✅ 重新安装依赖：rm -rf node_modules && npm install
✅ 检查环境变量是否正确设置
调整建议：
✅ 使用异步模式（async: true）
✅ 降低分辨率（720p代替1080p）
✅ 减少视频时长（推荐5秒）
✅ 简化prompt描述
模型名称 | 说明 | 推荐场景 |
| 最新第四代模型（默认） | 全场景推荐 |
| 第三代模型，画面鲜明 | 风格化创作 |
| 稳定版本 | 常规生成 |
| Pro版本 | 高质量需求 |
模型名称 | 说明 | 推荐场景 |
| 主力模型（默认） | 全场景推荐 |
| Pro高质量版本 | 专业级作品 |
| 兼容性好 | 多场景适配 |
class NewJimengClient {
private httpClient: HttpClient // HTTP请求和认证
private imageUploader: ImageUploader // 图片上传
private creditService: NewCreditService // 积分管理
private videoService: VideoService // 视频生成
constructor(token?: string) {
this.httpClient = new HttpClient(token);
this.imageUploader = new ImageUploader(this.httpClient);
this.creditService = new NewCreditService(this.httpClient);
this.videoService = new VideoService(this.httpClient, this.imageUploader);
}
}指标 | 重构前 | 重构后 | 改进 |
总代码行数 | 5,268行 | 1,335行 | -74.6% |
核心类数量 | 9个 | 5个 | -44.4% |
继承层级 | 3层 | 0层 | 扁平化 |
类型安全 | 部分 | 完整 | 100% |
如果不使用npx方式，可以手动安装：
# 全局安装
npm install -g jimeng-web-mcp
# 或项目内安装
npm install jimeng-web-mcpClaude Desktop配置：
{
"mcpServers": {
"jimeng-web-mcp": {
"command": "node",
"args": ["/path/to/jimeng-web-mcp/lib/index.js"],
"env": {
"JIMENG_API_TOKEN": "你的sessionid"
}
}
}
}欢迎提交Issue和Pull Request！
GitHub仓库: LupinLin1/jimeng-web-mcp
npm包: jimeng-web-mcp
即梦AI官网: jimeng.jianying.com
MCP协议: modelcontextprotocol.io
⭐ 如果这个项目对你有帮助，请给个Star支持一下！
Made with ❤️ by LupinLin1
生成单张图像
| Name | Required | Description | Default |
|---|---|---|---|
| async | No | 是否异步模式，默认false（同步） | |
| model | No | 模型名称，支持: jimeng-4.5, jimeng-4.1, jimeng-4.0 (默认), jimeng-3.1, jimeng-3.0 | |
| prompt | Yes | 图像描述文本 | |
| filePath | No | 参考图绝对路径数组，最多4张 | |
| resolution | No | 分辨率选择，2k或4k，默认2k | 2k |
| aspectRatio | No | 宽高比: auto/1:1/16:9/9:16/3:4/4:3/3:2/2:3/21:9 | auto |
| negative_prompt | No | 负向提示词 | |
| sample_strength | No | 参考图影响强度0-1，默认0.5 | |
| reference_strength | No | 每张参考图的独立强度数组 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the core function without disclosing behavioral traits such as async mode, model selection, side effects, return format, or error handling. This leaves the agent with critical safety and behavioral gaps.
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, concise sentence that is front-loaded and immediately communicates the tool's purpose without any fluff. While it is very brief, it is appropriately concise and free of unnecessary detail.
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 (9 parameters, no annotations, no output schema), the one-sentence description is insufficient to understand invocation context, return values, or behavioral expectations. The description needs more context to be complete.
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 descriptions for all 9 parameters, including defaults and enums, achieving 100% coverage. The tool description adds no additional parameter semantics beyond what the schema already provides, 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 '生成单张图像' clearly states the tool's function: generate a single image. It uses a specific verb and resource, and the word 'single' distinguishes it from sibling tool 'image_batch' which handles multiple images.
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 generating a single image but does not explicitly state when to use it versus alternatives like image_batch or video tools. There is no mention of exclusions or preferred contexts, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
系列图片生成 - 用于生成高相关性的连续图片（如：房间系列、故事分镜、绘本画面、产品多角度）
| Name | Required | Description | Default |
|---|---|---|---|
| async | No | 是否异步模式，默认true（异步） | |
| model | No | 模型名称，支持: jimeng-4.5, jimeng-4.1, jimeng-4.0 (默认) | |
| prompts | Yes | 每张图片的完整描述数组（1-15个）。⚠️重要：每个描述应该是一小段话（不是单个词），重点描述该图与其他图的差异部分。示例：["现代客厅，灰色沙发靠窗，阳光洒入", "温馨卧室，米色床品，木质床头柜"] | |
| filePath | No | 可选参考图路径（影响整体风格，最多4张） | |
| basePrompt | No | 整体通用描述，会添加在最终prompt最前面。用于描述：产品基础信息（材质、颜色）、房子整体风格（三室两厅现代简约）、故事背景设定（赛博朋克世界观）等通用信息。示例："三室两厅现代简约风格，木地板，暖色调照明" | |
| resolution | No | 分辨率选择，2k或4k，默认2k | 2k |
| aspectRatio | No | 宽高比: auto/1:1/16:9/9:16/3:4/4:3/3:2/2:3/21:9 | auto |
| negative_prompt | No | 负向提示词 | |
| sample_strength | No | 参考图影响强度0-1，默认0.5 | |
| reference_strength | No | 每张参考图的独立强度数组 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the burden of behavioral disclosure. It mentions 'highly relevant' but does not reveal asynchronous behavior, return format, or any side effects. The schema already documents parameters, so the description adds only a quality trait.
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, concise sentence with illustrative examples, placing the core purpose upfront. It is efficient but perhaps too brief to fully convey operational expectations.
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 has 10 parameters and no output schema, yet the description never clarifies what the tool returns, how to handle async results, or any constraints on batch generation. This leaves an agent without critical operational context for a complex generation task.
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% with descriptions for all parameters, so the baseline is 3. The description does not add any parameter-specific meaning 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 generates a series of highly relevant continuous images, with concrete examples like room series, storyboards, and product angles. This distinguishes it from the sibling 'image' tool, which likely handles single images.
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 specific use cases (room series, storyboards, picture books, product multi-angle) that indicate when this tool is appropriate. However, it does not explicitly contrast with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
测试服务器连接
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 姓名 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits, but it only restates the purpose. It does not mention side effects (though likely none), return behavior, success/failure indication, or whether the operation is read-only. This is functionally a tautology of the tool name 'ping'.
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 sentence with no wasted words. It front-loads the verb and purpose, making it immediately clear what the tool does. Ideal 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?
For a simple tool, the description is too sparse. There is no output schema, so the description should explain what the tool returns (e.g., round-trip time, success status). It also omits any usage examples or preconditions. The description lacks enough context to use the tool effectively, especially given the ambiguous parameter.
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?
Although schema coverage is 100%, the parameter description '姓名' (name) is generic and misaligned with the tool's purpose of testing a server connection. The description does not clarify what 'name' refers to (e.g., server hostname, connection identifier). This semantic gap makes the parameter ambiguous and the description fails 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 '测试服务器连接' clearly states the tool tests a server connection, which is a specific action on a specific resource. It distinguishes itself from sibling tools like image or video by indicating a network connectivity check. However, it does not explicitly detail what kind of test (e.g., ICMP ping) or the exact resource being tested.
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?
No guidance is given about when to use this tool or how it compares to alternatives. The description simply states what it does but offers no context for selection, such as implying a health check or network troubleshooting scenario. Sibling tools are unrelated, so no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询任务状态和结果
| Name | Required | Description | Default |
|---|---|---|---|
| historyId | Yes | 任务ID |
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 only states the tool queries status and results, but does not disclose return format, polling behavior, or that results might be pending. This gives the agent minimal behavioral insight beyond the literal function.
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?
One short sentence that is front-loaded with the action and resource. There is no wasted wording, and the structure is efficient for the amount of information provided.
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 simple (1 param, no output schema), but the description lacks essential context such as how it relates to sibling generation tools, how to handle pending results, and any assumptions about the historyId (e.g., from a prior submission). These gaps leave the agent under-informed for correct 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 coverage is 100%, with historyId described as '任务ID' (task ID) and a pattern. The tool description adds no further parameter meaning, so the baseline 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 '查询任务状态和结果' (Query task status and results) clearly states a specific verb and resource. The sibling tools are generation tools (image, video, etc.), so this tool is distinctly a retrieval/status-check operation.
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?
No explicit guidance on when to use this tool versus alternatives. The description does not mention that it should be used to poll after submitting a task via the generation tools, nor does it state any exclusions or conditions. Usage is only implied by the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
纯文字生成视频
| Name | Required | Description | Default |
|---|---|---|---|
| fps | No | 帧率(12-30) | |
| async | No | 是否异步模式，默认true（异步） | |
| model | No | 模型名称 | jimeng-video-3.0 |
| prompt | Yes | 视频描述文本 | |
| duration | No | 时长(毫秒，3-15秒) | |
| resolution | No | 分辨率 | 720p |
| videoAspectRatio | No | 视频宽高比 | 16:9 |
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 fails to disclose key behavioral traits such as async processing (the 'async' parameter defaults to true), potential long execution times, or response format (e.g., task ID). The one-line description adds no depth beyond the basic operation.
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 short phrase, extremely concise and front-loaded. It wastes no words, though it might benefit from more detail. Conciseness is high, but it borders on under-specification.
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 7 parameters, no output schema, and no annotations, the description is insufficiently complete. It lacks context on how to handle asynchronous mode, how to retrieve generated video results, and potential constraints. The one-line description is inadequate for the tool's complexity.
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?
All 7 parameters have descriptions in the schema (100% coverage), so the schema already documents parameters fully. The description adds no additional parameter meaning, making the baseline 3 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 '纯文字生成视频' (generate video from pure text) clearly states the tool's function with a specific verb and resource, and differentiates from siblings like video_multi or video_mix which imply different use cases. However, it doesn't explicitly name alternatives, so it's clear but not fully distinguishing.
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 such as video_multi or video_mix. It is a bare statement of function without context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
首尾帧控制视频
| Name | Required | Description | Default |
|---|---|---|---|
| fps | No | 帧率(12-30) | |
| async | No | 是否异步模式，默认true（异步） | |
| model | No | 模型名称 | jimeng-video-3.0 |
| prompt | Yes | 视频描述文本 | |
| duration | No | 时长(毫秒，3-15秒) | |
| resolution | No | 分辨率 | 720p |
| lastFrameImage | No | 尾帧图片路径 | |
| firstFrameImage | No | 首帧图片路径 | |
| videoAspectRatio | No | 视频宽高比 | 16:9 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for disclosing behavioral traits. It does not mention whether the tool generates video, operates asynchronously, requires specific input formats, or what side effects or return values to expect. The single phrase reveals nothing about actual 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 a single phrase, but it is under-specified rather than concise. It does not provide essential information and could be expanded meaningfully without adding waste, so it does not earn high marks for structure.
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 (9 parameters, no output schema, no annotations) the description is grossly incomplete. It fails to explain the core operation, usage context, or expected result, making it inadequate for an AI 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 description coverage is 100%, so both required and optional parameters have individual descriptions. The tool description adds no extra meaning beyond the schema, which already adequately explains each parameter, meeting the baseline for high schema coverage.
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 '首尾帧控制视频' hints at using first/last frames to control video, but lacks a specific verb (e.g., generate, edit) and does not distinguish it from sibling tools like 'video' or 'video_multi'. It is a vague purpose statement, not a clear action-resource description.
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?
No guidance is provided on when to use this tool versus alternatives such as 'video', 'video_multi', or 'video_mix'. The description gives no context for scenarios where first/last frame conditioning is appropriate, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
融合多张图片主体到一个场景
| Name | Required | Description | Default |
|---|---|---|---|
| fps | No | 帧率(12-30) | |
| async | No | 是否异步模式，默认true（异步） | |
| model | No | 模型名称 | jimeng-video-3.0 |
| prompt | Yes | 提示词，使用[图N]语法引用图片，例如：[图0]的猫在[图1]的地板上跑 | |
| duration | No | 时长(毫秒，3-15秒) | |
| resolution | No | 分辨率 | 720p |
| referenceImages | Yes | 参考图片路径数组（2-4张） | |
| videoAspectRatio | No | 视频宽高比 | 16:9 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states a high-level purpose and fails to mention async behavior, model selection, potential side effects, or output format. For a video generation 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 is a single, short sentence with no redundancy or filler. It is front-loaded and easy to parse. It is appropriately concise, though it sacrifices detail for brevity, which is a minor drawback but not a structural issue.
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 8 parameters and no output schema, the description is insufficient for complete contextual understanding. It does not mention return values, how to handle async mode, or required prompt syntax. The description relies entirely on the schema, which is rich but still leaves the agent without high-level context about 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?
The schema covers 100% of the parameters, so the baseline is 3. The description adds minimal semantic context by referencing 'multiple images' (referenceImages) and 'one scene' (prompt), but it does not explain the [图N] syntax or other parameter constraints. It stays at baseline.
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: merging subjects from multiple images into one scene. This is a specific verb+resource combination that conveys the core purpose. However, it does not differentiate from sibling tools like video_multi, which likely has a similar function, so it loses one point.
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 such as video, video_multi, or video_frame. There are no exclusions, prerequisites, or contextual examples, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
关键帧动画视频 - 提供2-10个关键帧图片，系统在帧间生成平滑过渡动画
| Name | Required | Description | Default |
|---|---|---|---|
| fps | No | 帧率(12-30) | |
| async | No | 是否异步模式，默认true（异步） | |
| model | No | 模型名称 | jimeng-video-3.0 |
| frames | Yes | 关键帧数组（2-10个）。每帧必须包含图片、过渡时长、动画描述。⚠️注意：最后一帧的prompt不生效。示例：[{idx:0,imagePath:"/path/1.jpg",duration_ms:2000,prompt:"镜头从正面推进，猫站起"},{idx:1,imagePath:"/path/2.jpg",duration_ms:1000,prompt:"忽略"}] | |
| resolution | No | 分辨率 | 720p |
| videoAspectRatio | No | 视频宽高比 | 16:9 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior (generating smooth transitions between keyframes) but does not mention other behavioral aspects such as asynchronous processing, duration limits, or that the last frame's prompt is ignored (these are only in the schema). With no annotations, the description carries the burden but provides minimal 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 is a single, concise sentence that immediately states the tool's purpose. It is front-loaded and contains no filler, making it highly efficient.
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 (6 parameters, no output schema, no annotations), the description is quite minimal. While the schema is extensive, the description lacks information about the expected output, how to retrieve results, or how this tool fits with siblings like video_frame. It is adequate but has clear 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 provides 100% coverage of parameter descriptions with detailed explanations, examples, and constraints. The description does not add any parameter semantics beyond what the schema already contains, 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 clearly states it generates keyframe animation videos by taking 2-10 keyframe images and producing smooth transitions. This identifies the specific function and distinguishes it from sibling tools like video_mix or video_frame.
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 when to use the tool (when you have 2-10 keyframe images) but does not provide explicit exclusions or mention alternative tools. It gives clear context but lacks explicit alternatives.
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.
v2.1.2imageimage_batchpingqueryvideovideo_framevideo_mixvideo_multiScored across 8 tools
Each tool serves a distinct purpose: ping checks connectivity, image and image_batch handle single vs. series generation, query fetches task status, and video, video_frame, video_multi, and video_mix cover different video generation modes. The video tools could cause some confusion since they all generate videos, but their input differences are clearly described.
Video tools share a consistent 'video' prefix, and image tools have a clear 'image' base. However, ping and query are verbs while image and video are nouns, and video_mix uses a verb suffix, causing a mix of conventions that is still readable but not fully predictable.
With 8 tools covering both image and video generation plus a status query, the server is well-scoped. Each tool has a distinct role, and the count is within the ideal 3-15 range, neither too sparse nor overloaded.
The core lifecycle of generation and result retrieval is covered for both images and videos. Minor gaps exist, such as no explicit tool for image editing (e.g., inpainting) or listing available models, but these are non-essential for a basic generation workflow.
Create images and videos from prompts, with options for image mixing, reference images, and start/…
Generate AI images and videos from 89 models on one credit balance, refunds on failure.
AI image, video & music generation. Flux, Veo 3.1, Suno V5. Free tier included.
AI image generation across 5 quality tiers (SDXL to Gemini 3 Pro), 50 free credits on signup.
