Click on "Install 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., "@image-video-generation-mcp Generate an image of a cat sitting on a chair"
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.
一个免费生成图像和视频的 MCP (Model Context Protocol) 服务器，支持 BigModel AI 平台的 CogView 和 CogVideoX 模型。
🎨 图像生成: 使用 CogView 模型（cogview-4, cogview-4-250304, cogview-3-flash）生成高质量图像，默认使用 cogview-3-flash 免费模型
🚀 批量图像生成: [新功能] 支持一次性生成1-100张图像，具备并行处理和灵活批次管理能力
🎬 视频生成: 使用 CogVideoX 模型（cogvideox-3, cogvideox-2, cogvideox-flash）生成视频，默认使用 cogvideox-flash 模型
⚙️ 配置管理: 支持环境变量配置和动态设置更新
🔄 异步处理: 支持视频生成任务状态查询和自动等待完成
🛡️ 错误处理: 内置重试机制和详细错误信息
📝 TypeScript: 完整的类型安全支持
🔧 调试支持: 内置 MCP Inspector 和 VS Code 调试配置
🎯 无水印: 默认生成无水印内容（可以在 bigmodel.cn 安全管理中去掉水印）
Related MCP server: Jimeng MCP Server
pnpm add -g image-video-generation-mcp在使用本服务器之前，您需要在 BigModel.cn 平台申请 API Key。
访问 BigModel 开放平台
点击右上角"登录"或"注册"
注册/登录账号
使用手机号或邮箱注册账号
完成实名认证（根据平台要求）
登录到开发者控制台
获取 API Key
点击右上角头像，找到 API Key 后点击进入
添加新的 API Key（注意保密）
免费额度: 新用户通常会获得一定的免费调用额度
计费方式: 按实际调用次数和资源使用量计费
余额查询: 在控制台可以查看余额和使用情况
充值方式: 支持多种在线充值方式
模型类型 | 模型名称 | 费用类型 | 推荐场景 |
图像生成 | cogview-3-flash | 免费/低成本 | 快速原型、日常使用 |
图像生成 | cogview-4 | 付费 | 高质量图像、专业用途 |
视频生成 | cogvideox-flash | 免费 | 快速视频生成 |
视频生成 | cogvideox-3 | 付费 | 标准质量视频 |
💡 建议: 开发和测试阶段建议使用免费模型（cogview-3-flash），生产环境根据需求选择付费模型。
🔒 保密: API Key 相当于密码，请勿在代码仓库中公开
✅ 权限: 确保 API Key 有权限访问所需的模型服务
🔄 轮换: 定期更换 API Key 以提高安全性
📊 监控: 定期检查 API 使用量和费用情况
设置环境变量：
export IMAGE_VIDEO_GENERATION_API_KEY="your_api_key_here"
export IMAGE_VIDEO_GENERATION_DEFAULT_IMAGE_MODEL="cogview-3-flash"
export IMAGE_VIDEO_GENERATION_DEFAULT_VIDEO_MODEL="cogvideox-flash"或创建配置文件 .image-video-generation-config.json：
{
"apiKey": "your_api_key_here",
"defaultImageModel": "cogview-3-flash",
"defaultVideoModel": "cogvideox-flash",
"timeout": 30000,
"maxRetries": 3
}在你的 MCP 客户端配置中添加：
{
"mcpServers": {
"image-video-generation": {
"command": "npx",
"args": ["-y", "image-video-generation-mcp@latest"],
"env": {
"IMAGE_VIDEO_GENERATION_API_KEY": "your_api_key"
},
"type": "stdio"
}
}
}重要说明: MCP 服务器通过 stdio 进行通信，所以直接运行
npx image-video-generation-mcp@latest会看起来像是"卡住"或"无法运行"，这是正常现象。服务器正在等待来自 MCP 客户端的输入。
注意: 模型配置是可选的，如果不设置环境变量，将使用默认模型：
默认图像模型:
cogview-3-flash默认视频模型:
cogvideox-flash
环境变量 | 必需 | 默认值 | 说明 |
| ✅ | - | API 密钥 |
| ❌ |
| 默认图像生成模型 |
| ❌ |
| 默认视频生成模型 |
生成单张图像，支持以下参数：
prompt (必需): 图像描述文本
model: 模型选择 (cogview-4, cogview-4-250304, cogview-3-flash)
quality: 图像质量 (standard, hd)
size: 图像尺寸 (例如 1024x1024)
watermark_enabled: 是否添加水印
user_id: 用户追踪 ID
[新功能] 批量生成多张图像，支持1-100个提示词，具备并行处理能力。
基础参数：
prompts (必需): 提示词数组，最多100个
model: 模型选择 (cogview-4, cogview-4-250304, cogview-3-flash)
quality: 图像质量 (standard, hd)
size: 图像尺寸 (例如 1024x1024)
watermark_enabled: 是否添加水印
user_id: 用户追踪 ID
批次管理参数：
batch_size: 每批处理的提示词数量 (1-20，默认4)
parallel: 是否并行处理 (默认true)
max_concurrent: 最大并发数 (1-10，默认3)
delay_between_batches: 批次间延迟(毫秒，0-10000，默认1000)
使用示例：
{
"prompts": ["小猫玩耍", "城市夜景", "程序员工作"],
"model": "cogview-3-flash",
"batch_size": 3,
"parallel": true,
"max_concurrent": 2
}📖 详细使用指南: BATCH_GENERATION_GUIDE.md
生成视频，支持以下参数：
prompt (必需): 视频描述文本 (最大 512 字符)
model: 模型选择 (cogvideox-3, cogvideox-2, cogvideox-flash)
quality: 输出质量模式 (speed, quality)
size: 视频分辨率 (例如 1920x1080)
fps: 帧率 (30, 60)
duration: 视频时长 (5, 10 秒)
with_audio: 是否启用 AI 生成音频
watermark_enabled: 是否控制水印
查询异步视频生成任务结果：
task_id (必需): 视频生成任务返回的 ID
等待视频生成完成并返回结果：
task_id (必需): 任务 ID
max_wait_time: 最大等待时间 (默认 300000 毫秒)
poll_interval: 轮询间隔 (默认 5000 毫秒)
配置默认模型和设置：
default_image_model: 默认图像生成模型
default_video_model: 默认视频生成模型
timeout: 请求超时时间
max_retries: 最大重试次数
图像生成: cogview-3-flash (免费模型，快速生成)
视频生成: cogvideox-flash (快速视频生成)
# 克隆项目
git clone https://github.com/156554395/image-video-generation-mcp.git
cd image-video-generation-mcp
# 安装依赖
pnpm install
# 开发模式
pnpm dev
# 运行测试
pnpm test
# 构建
pnpm build# 登录 npm（如果尚未登录）
npm login
# 发布新版本
pnpm release
# 或者手动发布
pnpm build
pnpm test
npm publishprepublishOnly: 发布前自动构建和测试
prepack: 打包前自动构建
release: 完整的发布流程（构建 → 测试 → 发布）
通过 package.json 中的 files 字段和 .npmignore 文件，发布包将只包含：
包含的文件：
dist/ - 构建后的 JavaScript 和 TypeScript 声明文件
README.md - 项目文档
LICENSE - 许可证文件
排除的文件：
src/ - 源代码目录
scripts/ - 开发脚本
测试文件和调试文件
配置文件和开发工具文件
# 更新补丁版本 (1.0.0 -> 1.0.1)
npm version patch
# 更新次版本 (1.0.0 -> 1.1.0)
npm version minor
# 更新主版本 (1.0.0 -> 2.0.0)
npm version major
# 预发布版本 (1.0.0 -> 1.0.1-beta.0)
npm version prerelease --preid=beta使用 VS Code 调试配置：
打开 VS Code
按 F5 或点击调试面板
选择 "Debug MCP Server" 配置
设置断点并开始调试
调试配置选项：
Debug MCP Server: 普通调试模式
Debug MCP Server (Break at Start): 启动时暂停
Debug Tests: 调试测试代码
启动调试服务器：
# 构建项目
pnpm build
# 启动调试（在第一行断点）
pnpm debug:break
# 或者启动调试（不在第一行断点）
pnpm debug使用 Chrome DevTools：
打开 Chrome 浏览器
访问 chrome://inspect
点击 "Open dedicated DevTools for Node"
在 DevTools 中查看和控制调试
使用 Node Inspector：
# 使用 inspector
node --inspect --inspect-port=9229 dist/index.js
# 使用 inspector-brk（启动时暂停）
node --inspect-brk --inspect-port=9229 dist/index.js# 设置调试环境变量
export NODE_ENV=development
export DEBUG=mcp:*启动 MCP Inspector：
# 构建项目
pnpm build
# 使用 MCP Inspector（推荐方式）
pnpm inspector
# 或者直接使用 npx
pnpm inspector:directMCP Inspector 功能：
🎯 可视化调试: 直观的 Web 界面调试 MCP 服务器
🛠️ 工具测试: 直接在浏览器中测试所有 MCP 工具
📝 实时日志: 查看服务器日志和调试信息
🔧 参数编辑: 动态修改请求参数进行测试
📊 响应预览: 查看工具执行的详细响应
Inspector 使用方法：
运行 pnpm inspector 命令
浏览器会自动打开 Inspector 界面
在左侧选择要测试的工具
填写参数并点击"Execute"执行
在右侧查看执行结果和日志
断点调试: 在源代码中设置断点，调试器会在这些点暂停执行
控制台输出: 使用 console.log() 输出调试信息
变量监视: 在调试器中监视变量值的变化
调用堆栈: 查看函数调用链，了解程序执行流程
热重载: 使用 pnpm dev 进行开发，自动重新编译
MCP Inspector: 最佳调试方式，提供完整的可视化和交互功能
MIT License - 详见 LICENSE 文件
欢迎提交 Issue 和 Pull Request！
Fork 项目
创建功能分支 (git checkout -b feature/AmazingFeature)
提交更改 (git commit -m 'Add some AmazingFeature')
推送到分支 (git push origin feature/AmazingFeature)
创建 Pull Request
感谢所有为这个项目做出贡献的开发者！
如果遇到 MCP 连接不上的问题，请检查以下几点：
API Key 配置：确保已正确设置 IMAGE_VIDEO_GENERATION_API_KEY 环境变量
# 测试 API Key 是否正确配置
IMAGE_VIDEO_GENERATION_API_KEY=your_api_key npx image-video-generation-mcp@latest网络连接：确保能访问 https://open.bigmodel.cn/api
版本问题：使用最新版本
# 清除 npm 缓存并使用最新版本
npm cache clean --force
npx -y image-video-generation-mcp@latest配置文件格式：确保 MCP 配置文件格式正确
{
"mcpServers": {
"image-video-generation": {
"command": "npx",
"args": ["-y", "image-video-generation-mcp@latest"],
"env": {
"IMAGE_VIDEO_GENERATION_API_KEY": "your_actual_api_key_here"
},
"type": "stdio"
}
}
}错误日志：如果仍有问题，请查看 MCP 客户端的错误日志
"API Key is required"：需要设置 IMAGE_VIDEO_GENERATION_API_KEY 环境变量
"command not found"：npm 缓存问题，尝试清除缓存或等待几分钟
连接超时：检查网络连接和防火墙设置
如有问题，请提交 GitHub Issues。
批量生成多张图像，支持并行处理和批次管理
| Name | Required | Description | Default |
|---|---|---|---|
| prompts | Yes | 提示词数组，最多支持100个 | |
| model | No | 使用的模型 (cogview-4, cogview-4-250304, cogview-3-flash) | |
| quality | No | 图像质量 | standard |
| size | No | 图像尺寸 (例如: 1024x1024, 1024x1792) | 1024x1024 |
| watermark_enabled | No | 是否添加水印 | |
| user_id | No | 用户ID，用于跟踪 (6-128个字符) | |
| batch_size | No | 每批处理的提示词数量 | |
| parallel | No | 是否并行处理批次内的请求 | |
| max_concurrent | No | 并行处理时的最大并发数 | |
| delay_between_batches | No | 批次间的延迟时间（毫秒） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions parallel processing and batch management but does not disclose error handling, rate limits, idempotency, or other behavioral traits. The description is too brief to adequately inform the agent.
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, concise and front-loaded. However, it is in Chinese, which may reduce clarity for English-speaking agents. Still, it earns its place without waste.
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 10 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return format, error states, or how batch results are returned. More detail is needed for a tool of this 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?
Schema coverage is 100%, so parameters are already documented. The description adds minimal value, only hinting at parallel and batch parameters. Since coverage is high, baseline is 3, and the description does not go beyond that.
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 action '批量生成多张图像' (batch generate multiple images) and mentions key capabilities like parallel processing and batch management, distinguishing it from siblings like generate_image (single image) and generate_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?
No explicit guidance on when to use this tool versus alternatives. The name implies batch processing, but the description lacks when/when-not advice. Sibling names provide some implicit distinction but the description itself does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure default models and settings
| Name | Required | Description | Default |
|---|---|---|---|
| default_image_model | No | Default image generation model | |
| default_video_model | No | Default video generation model | |
| timeout | No | Request timeout in milliseconds | |
| max_retries | No | Maximum retry attempts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether state is modified, persistence, side effects, or required permissions. The brief description gives no transparency beyond the action name.
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 efficient sentence with no redundancy. It is appropriately sized but could be structured slightly better with additional context.
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 four parameters and no output schema, the description is incomplete. It does not explain behavior like persistence, effect on future calls, or return value. More context is needed for a mutable configuration 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 coverage is 100%, with each parameter described. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 applies.
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 uses the verb 'Configure' and specifies the resource 'default models and settings', clearly differentiating from sibling tools that handle generation and querying. However, it is somewhat generic and could be more specific about which models and settings.
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 prerequisites, ordering relative to generation tools, or context for configuration. The description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate images using BigModel CogView models
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text description of the image to generate | |
| model | No | Model to use (cogview-4, cogview-4-250304, cogview-3-flash) | cogview-3-flash |
| quality | No | Image quality | standard |
| size | No | Image size (e.g., 1024x1024, 1024x1792) | 1024x1024 |
| watermark_enabled | No | Whether to add watermark | |
| user_id | No | User ID for tracking (6-128 characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'Generate images' without mentioning side effects, required permissions, rate limits, or other behavioral traits. This is insufficient for an agent to understand the tool's impact.
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, front-loaded sentence with no wasted words. It is efficient and directly communicates the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, no annotations, and multiple siblings, the description is too brief. It lacks differentiation, usage context, and behavioral details, making it incomplete for effective tool selection and invocation.
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 the baseline is 3. The description adds no additional meaning beyond the schema; it merely names the model family. The agent must rely entirely on the schema for parameter understanding.
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 action (generate) and resource (images) using BigModel CogView models. However, it does not differentiate this tool from its sibling 'batch_generate_images', which likely performs batch generation. The purpose is clear but lacks specificity about single vs. batch.
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 usage guidelines are provided. The description does not indicate when to use this tool over alternatives like 'batch_generate_images', 'generate_video', or others. The agent is given no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate videos using BigModel CogVideoX models
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text description of the video to generate (max 512 characters) | |
| model | No | Model to use | cogvideox-flash |
| quality | No | Output quality mode | quality |
| size | No | Video resolution (e.g., 1920x1080, 1280x720) | 1920x1080 |
| fps | No | Frame rate | |
| duration | No | Video duration in seconds | |
| with_audio | No | Enable AI-generated audio | |
| watermark_enabled | No | Control watermark |
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 does not disclose behavioral traits such as asynchronous processing, cost, or side effects. The sibling wait_for_video implies async behavior, but the description remains silent.
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, clear sentence that is appropriately front-loaded. It is concise but could be more informative without sacrificing brevity.
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 complexity (8 parameters, 4 enums, no output schema), the description is insufficient. It does not explain return values, whether the generation is synchronous or async, or any limitations beyond the schema.
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% and the input schema provides adequate descriptions for all 8 parameters. The tool description adds no additional meaning beyond the schema, meeting baseline expectations.
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 'Generate videos using BigModel CogVideoX models', specifying the verb (generate), resource (videos), and provider. It distinguishes from sibling tools like generate_image and batch_generate_images, which are for 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?
No guidance is given on when to use this tool versus alternatives. Siblings like query_video_result and wait_for_video suggest async behavior, but the description does not mention context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the result of an asynchronous video generation task
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The task ID returned from video generation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose what happens if the task is still processing, errors occur, or the shape of the response. For a query tool, this behavioral information is critical.
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 no unnecessary words. It efficiently captures the core purpose.
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 asynchronous nature and lack of output schema, the description is insufficient. It does not explain return values, possible states (pending/completed/failed), or how to interpret results, leaving the agent with significant ambiguity.
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 parameter task_id, and the parameter description is adequate. However, the tool description adds no additional semantic value beyond what the schema provides, so 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 uses the verb 'query' and resource 'result of an asynchronous video generation task', which clearly indicates the tool's function. It distinguishes from siblings like generate_video (creation) and wait_for_video (polling), but could be more specific about what data the result contains.
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 on when to use this tool versus siblings like wait_for_video. The agent is not told whether to use this after a certain time, or if it is a one-time check. Missing prerequisites or context about task completion state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for video generation to complete and return the result
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The task ID returned from video generation | |
| max_wait_time | No | Maximum wait time in milliseconds (default: 300000) | |
| poll_interval | No | Polling interval in milliseconds (default: 5000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It implies polling behavior but does not disclose timeout handling, rate limits, or whether it throws exceptions on failure. Minimal behavioral disclosure.
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?
A single sentence that is front-loaded with the key action ('Wait for video generation to complete') and includes the outcome ('return the result'). No wasted words.
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?
Despite having a clear purpose and well-documented parameters, the description lacks details about return format or error behavior, which is important since no output schema is provided. Adequate but not comprehensive.
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?
Input schema has 100% description coverage for all three parameters. The description adds no additional meaning beyond what the schema already provides, meeting the baseline of 3.
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 waits for video generation to complete and returns the result, which distinguishes it from sibling tools like generate_video (which initiates generation) and query_video_result (which likely checks status once).
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 on when to use this tool versus query_video_result or other siblings. It does not mention that it should be called after generate_video or that it polls until completion, missing context for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are mostly distinct: two image generators (single vs batch) and two video result tools (query vs wait) are related but have clear differences. configure_models is separate. Some potential confusion between the image generation tools without careful reading.
All names use snake_case but verbs vary: 'generate', 'batch_generate', 'configure', 'query', 'wait_for'. The prefix 'generate' is used in three tools but not uniformly. Inconsistent verb patterns reduce predictability.
Six tools cover the core workflow of image and video generation, including configuration and asynchronous result retrieval. The count is well-scoped for this domain.
The tool set covers the main generation tasks (single/batch image, video) and includes async support and model configuration. Minor gaps like image variation or editing are not expected for a basic generation server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate AI images and videos from any compatible MCP client.
Multi-model AI image and video generator. 14 models behind one OAuth-secured MCP endpoint.
Remote MCP for AI video, image, music and speech generation.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/156554395/image-video-generation-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
