Agnes Media MCP Server
This server enables AI-powered image and video generation directly from Claude Desktop using natural language, with results automatically saved locally.
Image Generation (
agnes_generate_image): Generate images from text prompts (text-to-image) or transform existing images (image-to-image) using Agnes Image 2.1 Flash. Configurable options include output size (1K–4K), aspect ratios (1:1, 16:9, 9:16, etc.), seed, negative prompt, and optional inline previews.Video Generation (
agnes_generate_video): Create videos using Agnes Video V2.0 via text-to-video, image-to-video (single image URL), or keyframe transition (multiple image URLs). Configurable parameters include resolution, frame count (up to 441, 8n+1), frame rate (1–60 fps), seed, and negative prompt.Async Video Polling (
agnes_get_video_status): Since video generation takes minutes, the server returns avideo_idimmediately. Poll this tool to check task progress and optionally download the final.mp4when complete.Local File Saving: All generated images and videos are automatically saved to configurable local directories (default: system Pictures/Videos folders under
AgnesOutputs/).Network Resilience: API calls include automatic retry logic (up to 4 attempts) to handle transient errors or rate limits.
Cross-Platform: Runs on Node.js, compatible with macOS and Windows, and integrates seamlessly with Claude Desktop.
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., "@Agnes Media MCP Servergenerate a 16:9 cyberpunk city wallpaper"
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.
Agnes Media MCP Server
一个用于 Claude Desktop 的本地 MCP 服务器,内置:
Agnes Image 2.1 Flash (
agnes-image-2.1-flash) — 文生图 / 图生图Agnes Video V2.0 (
agnes-video-v2.0) — 文生视频 / 图生视频 / 关键帧动画(异步)
接入后,在 Claude Desktop 里用自然语言即可生成图片和视频,结果自动落盘到本地目录。
跨平台:服务器由 Node 运行,macOS 与 Windows 均可使用。
工具
工具 | 说明 |
| 生成图片。默认文生图;传 |
| 创建视频任务并短等待(默认 45s)。若在等待窗口内完成则直接下载 mp4;否则立即返回 |
| 按 |
视频时长:seconds = num_frames / frame_rate。num_frames 必须 ≤ 441 且满足 8n+1(如 81≈3s、121≈5s、241≈10s、441≈18s @ 24fps)。
为什么视频要两步:视频生成通常需要数分钟,超过单次 MCP 请求的超时(约 60s)。因此 agnes_generate_video 只在客户端超时预算内(wait_seconds,默认 45s、上限 50s)内联等待——快的视频一次返回;慢的立即交回 video_id,用 agnes_get_video_status(download:true)每隔约 15s 轮询直到 completed 即可拿到文件。
Related MCP server: Jimeng MCP Server
安装与构建
npm install
npm run build生成 dist/index.js。
配置(环境变量)
变量 | 必填 | 默认 | 说明 |
| 是 | — | Agnes AI API Key |
| 否 | 系统图片/视频文件夹 | 覆盖输出根目录(设置后图片→ |
| 否 |
| API 网关地址 |
默认落盘位置:不设 AGNES_OUTPUT_DIR 时,图片保存到系统"图片"文件夹、视频保存到系统"视频"文件夹,各自放在 AgnesOutputs/ 子目录下。Windows 上会读取真实的已知文件夹路径(支持重定向,如 H:\用户文件\图片);macOS/Linux 回退到 ~/Pictures、~/Videos。
网络重试:所有 API 调用与文件下载都带自动重试(网络失败或 429/5xx 时等 2 秒重试,共 4 次尝试),以应对偶发的网络抖动。
接入 Claude Desktop
编辑 Claude Desktop 配置文件:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json(不同版本的路径可能不一样)
加入(把路径换成本机 dist/index.js 的绝对路径):
{
"mcpServers": {
"agnes-media": {
"command": "node",
"args": ["/绝对路径/图片和视频MCP/dist/index.js"],
"env": {
"AGNES_API_KEY": "你的Key",
"AGNES_OUTPUT_DIR": "可选自定义输出目录"
}
}
}
}Windows 下
args路径示例:"C:\\Users\\you\\projects\\图片和视频MCP\\dist\\index.js"(反斜杠需转义,或用正斜杠)。
保存后完全重启 Claude Desktop。连接成功后即可对 Claude 说:“生成一张 16:9 的霓虹灯城市壁纸”。
本地调试
用官方 MCP Inspector 手动调用工具:
AGNES_API_KEY=你的Key npm run inspect在 Inspector 里:
agnes_generate_image—prompt任意,size: "2K",ratio: "16:9"→ 检查系统「图片」文件夹下AgnesOutputs/出图。agnes_generate_video—num_frames: 121, frame_rate: 24→ 等待轮询完成,检查系统「视频」文件夹下AgnesOutputs/出 mp4。agnes_get_video_status— 传上一步的video_id。
注意事项
日志走 stderr,stdout 专供 MCP 协议,请勿改动。
视频为异步生成,可能需要数分钟;服务器会阻塞轮询(默认间隔 5s、超时 10 分钟)。超时后可用
agnes_get_video_status继续查询。图生图不需要
tags;response_format由服务器自动放进extra_body。定价当前为 $0(图片 / 视频),可放心联调。
Available Tools
3 toolsagnes_generate_imageA
Generate an image with Agnes Image 2.1 Flash. Text-to-image by default; pass image_urls to do image-to-image (transform/restyle while preserving composition). The result is saved to the local output directory and a preview is returned inline.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Output size tier. 1K/2K/3K/4K. | 2K |
| ratio | No | Aspect ratio, e.g. 16:9 for wallpapers. | 1:1 |
| prompt | Yes | What to generate, or how to transform the input image(s). | |
| image_urls | No | Optional input images (public URL or data URI) to enable image-to-image. | |
| inline_preview | No | Also return the image inline as a preview (small files only). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that images are saved locally and a preview is returned inline (only for small files). However, it omits details such as whether the tool is blocking, if it overwrites existing files, any cost or rate limits, and the exact return format beyond a preview.
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?
Three sentences with no extraneous information. The description is front-loaded with the main purpose and is structured logically: mode explanation, then outcome.
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 core functionality and modes. However, it lacks details on output file naming, handling of duplicate file names, limitations on prompt length or image_urls count, and the structure of the inline preview response. Given no output schema, more completeness on return values would be helpful.
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 explaining the mode switch tied to image_urls and the size limitation for inline_preview. Other parameters (size, ratio, prompt) are not elaborated beyond the schema, so no significant added meaning.
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 images using a specific model (Agnes Image 2.1 Flash). It distinguishes between text-to-image and image-to-image modes, and given sibling tools are for video, the tool's purpose is unambiguous and distinct.
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 explicitly explains when to use each mode: text-to-image by default, image-to-image when image_urls are provided. It does not explicitly state when not to use the tool or provide alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
agnes_generate_videoA
Start an Agnes Video V2.0 generation (async). Text-to-video by default; pass image_url for image-to-video, or keyframe_urls (2+) for keyframe transitions. Video generation takes minutes, longer than an MCP request can block. This tool creates the task and waits up to wait_seconds for it to finish: if it completes in time, the mp4 is downloaded locally and its path returned; otherwise it returns the video_id immediately — poll agnes_get_video_status with that id (download:true) to fetch the result when ready. Duration = num_frames / frame_rate. num_frames must be <=441 and of the form 8n+1.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Random seed for reproducible results. | |
| width | No | Video width (default 1152). | |
| height | No | Video height (default 768). | |
| prompt | Yes | Text description of the video content / motion. | |
| image_url | No | Image URL for image-to-video. | |
| frame_rate | No | Frames per second (1-60). | |
| num_frames | No | Frame count (<=441, 8n+1). 81≈3s, 121≈5s, 241≈10s, 441≈18s at 24fps. | |
| wait_seconds | No | How long to wait inline for completion before handing off (0-50s). Kept under the MCP client request timeout; if the video isn't ready, the video_id is returned to poll. | |
| keyframe_urls | No | 2+ keyframe image URLs for keyframe-transition mode. | |
| negative_prompt | No | What to avoid in the video. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses async nature, blocking duration (wait_seconds), return behavior (local path vs. video_id), and constraints on num_frames (<=441, 8n+1). No contradictions.
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?
Single paragraph is functional and every sentence adds value, but could be more structured (e.g., bullet points for modes). Not too long, well-focused.
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 complex tool with 10 params and no output schema, description covers async flow, constraints, mode selection, and return values. Lacks explicit error handling details but sufficient for 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 coverage is 100% (baseline 3), but description adds significant value: explains mode parameter usage in prose, clarifies wait_seconds logic, and provides frame count examples (81≈3s, etc.) beyond schema descriptions.
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 clearly states it starts async video generation (Agnes V2.0), enumerates three modes (text-to-video, image-to-video, keyframe transitions), and distinguishes from siblings (agnes_get_video_status for polling, agnes_generate_image 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?
Explicitly explains when to use each mode, describes wait_seconds inline behavior, and directs polling with agnes_get_video_status upon timeout. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
agnes_get_video_statusA
Check the status of an Agnes video task by video_id. Returns status/progress, and if completed, the remote URL. Optionally downloads the mp4 locally when ready.
| Name | Required | Description | Default |
|---|---|---|---|
| download | No | If completed, download the mp4 to the local output directory. | |
| video_id | Yes | The video_id returned when the task was created. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses optional download, but lacks details on side effects (e.g., filesystem changes) or error states. No annotations, so description should provide more behavioral 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?
Two efficient sentences, front-loaded with purpose, 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?
Explains return values (status, URL) and optional download, but lacks output format details. Adequate for a simple poll 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 covers 100% of parameters with descriptions. Description adds little beyond schema; baseline 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?
Description clearly states the tool checks status of a video task, returns progress and URL, and optionally downloads. Distinguishes from sibling generation tools.
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?
Clear context: used after task creation to check status. No explicit exclusions or alternatives, but implied by sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v1.0.0- First observed
agnes_generate_image - First observed
agnes_generate_video - First observed
agnes_get_video_status
TDQS
Scored across 3 tools
Each tool targets a distinct operation: image generation, video generation (async), and video status retrieval. No overlap in purpose.
All tools follow a consistent 'agnes_verb_noun' pattern with underscores (e.g., generate_image, get_video_status). No mixing of styles.
3 tools is minimal but appropriate for the focused scope of image and video generation. Could be expanded with list/delete utilities, but not underpowered.
Covers core generation and status polling, but lacks list/delete or cancel operations for videos, and no tool for managing images beyond generation.
Maintenance
Related MCP Connectors
MCP server for Qwen Image 3 AI image generation
MCP server for Grok Imagine AI video generation
MCP server for Wan AI video generation
MCP server for Hailuo (MiniMax) AI video generation
Related MCP Servers
- AlicenseAqualityBmaintenanceMCP server for AI-powered image, audio, and video generation, enabling media creation directly from Claude, Cursor, and other MCP clients.1139 npmMIT
- FlicenseNot gradedqualityCmaintenanceA Model Context Protocol server for AI image and video generation using Jimeng AI, enabling text-to-image, image composition, text-to-video, and image-to-video through Claude Desktop and other MCP clients.78-
- FlicenseNot gradedqualityDmaintenanceA local MCP server that gives Claude Desktop full video editing capabilities via FFmpeg, Whisper, and yt-dlp.-
- AlicenseNot gradedqualityDmaintenanceA powerful MCP server that brings AI vision capabilities to Claude Desktop. Analyze images and videos using OpenAI GPT-4o, Claude, or any compatible vision API.11 npmMIT