Automatically syncs generated images to a Firebase-powered Web App gallery, allowing users to view and like images without login.
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., "@SeeDream MCP Server Generate a serene beach sunset with palm trees"
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.
让 Claude Code 直接生成图片的 MCP 服务器，基于 BytePlus SeeDream 4.5 模型。
工具 | 说明 | 示例 |
| 文本生成图片 | "生成一张赛博朋克城市夜景" |
| 编辑现有图片 | "给人物加上墨镜" |
| 多图融合 | "把图1人物穿上图2衣服" |
| 批量生成变体 | "生成4个不同配色方案" |
| 检查服务状态 | 验证 API Key 和服务健康状态 |
Firebase 集成: 生成的图片自动同步到 Web App 共享图库
无需登录: 所有人都能在 Web App 看到 MCP 生成的图片
Like 收藏: 用户登录后可以 like 收藏喜欢的图片
流式 API: 图片生成一张返回一张，无需等待全部完成，体感速度大幅提升
实时下载: 边生成边下载，图片到达即开始保存
并行下载: 最多 4 张图片同时下载，批量生成速度提升 ~60%
智能缓存: Base64 编码缓存，重复使用相同图片无需重新编码
自动重试: 下载失败自动重试 2 次，带指数退避
性能指标: 每次生成显示详细耗时（生成/下载/总计）
结构化输出: 所有工具支持 outputSchema，便于程序化处理
HTTP 模式: 支持作为远程服务器部署（设置 TRANSPORT=http）
访问 BytePlus ModelArk Console 获取 API Key。
# macOS/Linux
echo 'export ARK_API_KEY="your-api-key"' >> ~/.zshrc
source ~/.zshrc
# Windows (PowerShell)
[Environment]::SetEnvironmentVariable("ARK_API_KEY", "your-api-key", "User")在你的项目根目录创建 .mcp.json：
{
"mcpServers": {
"seedream": {
"type": "stdio",
"command": "npx",
"args": ["-y", "seedream-mcp-server"],
"env": {
"ARK_API_KEY": "${ARK_API_KEY}"
}
}
}
}或者添加到全局配置 ~/.claude.json：
{
"mcpServers": {
"seedream": {
"type": "stdio",
"command": "npx",
"args": ["-y", "seedream-mcp-server"],
"env": {
"ARK_API_KEY": "${ARK_API_KEY}"
}
}
}
}重启后即可使用！
在 Claude Code 中直接说：
生成一张日本樱花树下的咖啡店，温暖的下午阳光，插画风格把这张图片 ./photo.jpg 的背景换成星空把 person.jpg 的人物穿上 dress.jpg 的裙子基于这个 logo 生成6个不同配色方案生成的图片会自动保存到 ./generated_images/ 目录。
输出示例（带性能指标）：
# Image Generated Successfully
**Prompt:** 一只橘猫在阳光下打盹
**Size:** 2K
## Generated Images
### Image 1
- **URL:** https://...
- **Local:** `./generated_images/seedream_2024-01-27_12-30-45_1.jpg`
- **Size:** 2K
## Performance
- Generation: 15.2s
- Download: 1.8s
- **Total: 17.0s**Related MCP server: nano-banana-mcp-app
Tool | Description | Example |
| Text-to-image | "Generate a cyberpunk city at night" |
| Edit existing image | "Add sunglasses to the person" |
| Blend multiple images | "Dress person in image 1 with outfit from image 2" |
| Batch variations | "Generate 4 color variations" |
| Check server status | Verify API key and server health |
Firebase Integration: Generated images automatically sync to Web App shared gallery
No Login Required: Everyone can see MCP-generated images in the Web App
Like & Save: Logged-in users can like and save their favorite images
Streaming API: Images returned as they're generated, no waiting for all to complete
Real-time Downloads: Download starts immediately when each image is ready
Parallel Downloads: Up to 4 concurrent image downloads, ~60% faster for batch generation
Smart Caching: Base64 encoding cache for repeated image inputs
Auto Retry: Failed downloads retry up to 2 times with exponential backoff
Performance Metrics: Detailed timing for each generation (generation/download/total)
Structured Output: All tools support outputSchema for programmatic processing
HTTP Mode: Deploy as a remote server (set TRANSPORT=http)
Visit BytePlus ModelArk Console to get your API key.
# macOS/Linux
echo 'export ARK_API_KEY="your-api-key"' >> ~/.zshrc
source ~/.zshrc
# Windows (PowerShell)
[Environment]::SetEnvironmentVariable("ARK_API_KEY", "your-api-key", "User")Create .mcp.json in your project root:
{
"mcpServers": {
"seedream": {
"type": "stdio",
"command": "npx",
"args": ["-y", "seedream-mcp-server"],
"env": {
"ARK_API_KEY": "${ARK_API_KEY}"
}
}
}
}Or add to global config ~/.claude.json:
{
"mcpServers": {
"seedream": {
"type": "stdio",
"command": "npx",
"args": ["-y", "seedream-mcp-server"],
"env": {
"ARK_API_KEY": "${ARK_API_KEY}"
}
}
}
}Restart and you're ready to go!
Just talk to Claude Code:
Generate a serene Japanese garden with cherry blossoms, morning mist, photorealisticChange the background of ./photo.jpg to a beach sunsetDress the person in person.jpg with the outfit from dress.jpgGenerate 4 seasonal variations of this coffee shop interiorGenerated images are automatically saved to ./generated_images/.
要让 MCP 生成的图片自动同步到 Web App，需要配置 Firebase Service Account：
To sync MCP-generated images to the Web App, configure Firebase Service Account:
点击 "Generate new private key" 下载 JSON 文件
将文件保存到安全位置
# 方法一：指定文件路径 / Method 1: File path
export FIREBASE_SERVICE_ACCOUNT_PATH="/path/to/service-account.json"
# 方法二：JSON 字符串（适合 CI/CD）/ Method 2: JSON string (for CI/CD)
export FIREBASE_SERVICE_ACCOUNT='{"type":"service_account",...}'
# 方法三：标准 GCP 方式 / Method 3: Standard GCP approach
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json"{
"mcpServers": {
"seedream": {
"type": "stdio",
"command": "npx",
"args": ["-y", "seedream-mcp-server"],
"env": {
"ARK_API_KEY": "${ARK_API_KEY}",
"FIREBASE_SERVICE_ACCOUNT_PATH": "${FIREBASE_SERVICE_ACCOUNT_PATH}"
}
}
}
}配置完成后，MCP 生成的图片会自动出现在 SeeDream Gallery 中！
Once configured, MCP-generated images will automatically appear in SeeDream Gallery!
除了默认的 stdio 模式，还可以作为 HTTP 服务器运行：
In addition to the default stdio mode, you can run as an HTTP server:
# 启动 HTTP 服务器 / Start HTTP server
TRANSPORT=http PORT=3000 ARK_API_KEY=your-key node dist/index.js
# 或使用 npx / Or using npx
TRANSPORT=http PORT=3000 ARK_API_KEY=your-key npx seedream-mcp-server端点 / Endpoints:
POST /mcp - MCP 协议端点
GET /health - 健康检查
GET / - 服务器信息
MIT
Combine elements from multiple images using SeeDream 4.5.
⚠️ CLAUDE.AI USERS: This tool WILL TIMEOUT on Claude.ai (takes 30-60 seconds). Use "seedream_submit" instead with mode="multi" for Claude.ai compatibility.
Use this tool to blend 2-14 reference images together. Perfect for:
Virtual try-on: Dress person from image 1 in clothes from image 2
Face/Subject swap: Put face/subject from image 1 onto body/scene in image 2
Style transfer: Apply style of image 2 to content of image 1
Product visualization: Put product from image 1 into scene from image 2
Character consistency: Combine character traits from multiple references
Args:
prompt (string, required): Blending instruction referencing images by number
images (string[], required): Array of 2-14 image URLs or local paths
size (string): Output size (default: '2K')
strength (number): Reference strength 0-1 (default: 0.7)
watermark (boolean): Add watermark (default: false)
download (boolean): Save locally (default: true)
download_dir (string): Local save directory
Returns: Blended image URL, local path if downloaded, and performance timing.
Prompt Structure (per official docs):
Reference Target: Clearly specify what to extract from each reference image
Scene Description: Describe the output scene layout and composition
Always reference images by number: "image 1", "image 2", etc.
Common Use Cases:
Virtual try-on: "Dress the character in Image 1 with the outfit from Image 2"
Subject replacement: "Replace the subject in Image 1 with the subject from Image 2"
Style transfer: "Apply the style of Image 2 to Image 1"
Product placement: "Place the product from Image 1 on the table in Image 2"
Examples:
"Replace the clothing in image 1 with the outfit from image 2"
"Put the face from image 1 onto the body in image 2, maintaining natural lighting"
"Apply the linear minimalist style of image 2 to design icons based on image 1"
"Generate four tops in different materials, based on the clothing style worn by the girl in the reference images"
Tips:
Be specific about which elements to take from each image
For best results, use similar aspect ratios for inputs
Higher strength preserves more details from reference images
Using 10+ reference images significantly impacts generation speed
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Output image size | 2K |
| images | Yes | Array of image URLs or local file paths to blend | |
| prompt | Yes | Instruction for combining images. Reference images by number: 'Dress the person in image 1 with outfit from image 2' | |
| download | No | Whether to download generated images to local directory | |
| strength | No | Reference strength (0-1). Higher values preserve more from reference images. | |
| watermark | No | Whether to add 'AI generated' watermark | |
| download_dir | No | Local directory to save images (defaults to ./generated_images) | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for structured data | markdown |
| Name | Required | Description |
|---|---|---|
| usage | No | API usage metrics |
| images | Yes | Array of generated images |
| prompt | Yes | The prompt used for generation |
| timing | No | Performance timing metrics |
| success | Yes | Whether the generation was successful |
| strength | Yes | The strength value used for blending |
| image_count | Yes | Number of images blended |
| source_images | Yes | Array of source images used |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=false and destructiveHint=false, so the description does not need to restate those. It adds valuable behavioral context beyond the schema: the tool can take 30-60 seconds, will time out on Claude.ai, and using 10+ reference images significantly impacts generation speed. It also discloses return details such as URL, local path, and timing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections and front-loads the critical timeout warning. However, it is long and contains redundancy: the 'Perfect for' bullet list near the top substantially overlaps with the later 'Common Use Cases' section. It earns above-minimal credit for structure but loses points for repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the warning, use cases, parameter guidance, return behavior, prompt structure, examples, and practical tips. Given the output schema exists and annotations are present, an agent has everything needed to decide whether to call this tool and how to construct a valid multi-image blending request.
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 schema already documents all parameters, establishing a baseline of 3. The description adds meaningful extra guidance: how to structure prompts around numbered reference images, example prompts for different use cases, and an explanation that higher strength preserves more reference detail. It slightly over-relies on the schema for response_format, but overall it enhances 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 a specific verb and resource: 'Combine elements from multiple images using SeeDream 4.5.' It reinforces the purpose with concrete use cases such as virtual try-on, face swap, and style transfer, and the '2-14 reference images' constraint distinguishes it from sibling generation/edit/variation 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?
The description explicitly says 'Use this tool to blend 2-14 reference images together' and enumerates scenarios where it is appropriate. It also names an alternative tool and condition: Claude.ai users should use seedream_submit with mode='multi' instead due to timeout risk. This gives an agent clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an existing image based on text instructions using SeeDream 4.5.
⚠️ CLAUDE.AI USERS: This tool WILL TIMEOUT on Claude.ai (takes 20-40 seconds). Use "seedream_submit" instead with mode="image" for Claude.ai compatibility.
Use this tool to modify, enhance, or transform an existing image. Supports:
Addition: Add elements (accessories, objects, background elements)
Deletion: Remove unwanted elements
Replacement: Swap one element for another
Modification: Change colors, styles, lighting, expressions
Style transfer: Apply artistic styles to photos
Args:
prompt (string, required): Edit instruction describing the changes
image (string, required): Source image URL or local file path
size (string): Output size (default: '2K')
strength (number): Reference strength 0-1 (default: 0.7)
watermark (boolean): Add watermark (default: false)
download (boolean): Save locally (default: true)
download_dir (string): Local save directory
Returns: Edited image URL, local path if downloaded, and performance timing.
Edit Instruction Best Practices (per official docs):
Use concise, unambiguous instructions
Be specific: "the person's shirt" not "it"
Specify what should remain unchanged: "keeping the pose unchanged"
For targeted edits: draw arrows/boxes on image and reference them Example: "Insert a TV where the red area is marked"
Supported Operations:
Addition: "Add matching silver earrings and a necklace to the girl"
Deletion: "Remove the girl's hat"
Replacement: "Replace the largest bread man with a croissant man"
Modification: "Turn the robots into transparent crystal, colored red, yellow and green"
Examples:
"Add sunglasses to the person, keeping everything else unchanged"
"Change the background to a beach sunset"
"Apply Van Gogh oil painting style to this photo"
"Remove the text from the image"
"Dress the tallest panda in pink Peking Opera costume, keeping its pose unchanged"
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Output image size | 2K |
| image | Yes | Source image URL or local file path to edit | |
| prompt | Yes | Edit instruction describing what to change. Examples: 'Add sunglasses', 'Change background to beach', 'Make it look like oil painting' | |
| download | No | Whether to download generated images to local directory | |
| strength | No | How much to preserve the original image (0=ignore original, 1=strongly preserve). Lower values allow more creative changes. | |
| watermark | No | Whether to add 'AI generated' watermark | |
| download_dir | No | Local directory to save images (defaults to ./generated_images) | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for structured data | markdown |
| Name | Required | Description |
|---|---|---|
| usage | No | API usage metrics |
| images | Yes | Array of generated images |
| prompt | Yes | The prompt used for generation |
| timing | No | Performance timing metrics |
| success | Yes | Whether the generation was successful |
| strength | Yes | The strength value used for editing |
| source_image | Yes | The source image that was edited |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds important behavioral context: the tool can time out on Claude.ai (20-40 seconds), it modifies existing images (not read-only), and the strength parameter controls preservation vs. creativity. It also reveals that arrows/boxes on the image can be referenced for targeted edits, which is behavior not obvious from annotations or schema. There is no contradiction.
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 information-dense and well-structured with clear sections (supported operations, args, returns, best practices, examples). It is longer than minimal, but every section earns its place: the Claude.ai warning is critical, the supported operations list differentiates semantics, and examples are directly useful for generating prompts. Minor redundancy exists between the bullet list of args and the schema, but the description's arg list is a helpful quick reference.
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 image editing tool with 8 parameters, no nested objects, and an output schema, the description is remarkably complete. It covers the tool's purpose, safety/timing caveats, alternative routing (seedream_submit), parameter semantics, prompt best practices, and example invocations. The output schema exists, so the Returns section is sufficient without going into deeper detail. An agent has enough information to select this tool, construct valid parameters, and anticipate behavior.
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 every parameter has a description in the schema. However, the tool description adds meaning beyond the schema by explaining the strength parameter's semantic range (0=ignore original, 1=strongly preserve) and by providing prompt-writing best practices, including an example of referencing marked areas. The parameter list in the description is a condensed version of the schema, so it doesn't add much beyond what schema already provides, but the strength guidance and prompt guidance push it above the baseline 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 uses specific verbs (edit, modify, enhance, transform) with a clear resource (existing image) and names the underlying model (SeeDream 4.5). It distinguishes itself from siblings by explicitly contrasting with seedream_submit for Claude.ai users and by listing supported operations (addition, deletion, replacement, modification, style transfer), making the tool's scope unmistakable even among five sibling 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?
The description provides explicit when-to-use guidance: it tells Claude.ai users to use seedream_submit instead, and it lists concrete use cases with examples. It also offers best-practice instructions for writing edit prompts, which is actionable guidance for an agent deciding how to invoke the tool and construct parameters. This goes beyond simply stating purpose and explicitly names an alternative and exclusion condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate images from a text description using SeeDream 4.5.
⚠️ CLAUDE.AI USERS: This tool WILL TIMEOUT on Claude.ai (takes 30-60 seconds). Use "seedream_submit" instead with mode="text" for Claude.ai compatibility.
This is the primary tool for creating images from scratch. Default: Generates 4 images per prompt using streaming for fast response.
Args:
prompt (string, required): Detailed description of the image to generate
size (string): '2K' (default), '4K', '4K-9:16' (2304x4096 high-res vertical), or aspect ratios: '1:1', '4:3', '3:4', '16:9', '9:16', '3:2', '2:3', '21:9'
watermark (boolean): Add 'AI generated' watermark (default: false)
download (boolean): Save to local directory (default: true)
download_dir (string): Local save directory (default: ./generated_images)
response_format ('markdown' | 'json'): Output format
Returns: Generated image URL(s), local file path(s) if downloaded, and performance timing.
Prompt Best Practices (per official docs):
Structure: Subject + Action + Environment
For aesthetics add: Style, Color, Lighting, Composition
For text in images: use double quotes - 'poster with title "Hello World"'
Specify application context: "Design a logo for...", "Create a poster for..."
Keep under 600 English words; concise is better than verbose
Examples:
"A girl in a lavish dress walking under a parasol along a tree-lined path, in the style of a Monet oil painting"
"Design a logo for a gaming company. The logo features a dog playing with a game controller. The company name 'PITBULL' is written on it."
"Vibrant close-up editorial portrait, model with piercing gaze, wearing a sculptural hat, rich color blocking, Vogue magazine aesthetic"
"A cluttered office desk with an open laptop showing green code, a mug with the word 'Developer' on it, sunlight from the right"
Tips:
Be specific: "golden retriever puppy" > "dog"
Use natural language, not keyword lists
Include style keywords: "oil painting style", "anime art", "photorealistic"
Specify composition: "close-up portrait", "bird's eye view", "cinematic wide shot"
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Output image size: '2K' (default), '4K', '4K-9:16' (2304x4096 high-res vertical), or aspect ratios: '1:1', '4:3', '3:4', '16:9', '9:16', '3:2', '2:3', '21:9' | 2K |
| prompt | Yes | Text description of the image to generate. Be specific about subject, style, lighting, composition. | |
| download | No | Whether to download generated images to local directory | |
| watermark | No | Whether to add 'AI generated' watermark | |
| download_dir | No | Local directory to save images (defaults to ./generated_images) | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for structured data | markdown |
| Name | Required | Description |
|---|---|---|
| usage | No | API usage metrics |
| images | Yes | Array of generated images |
| prompt | Yes | The prompt used for generation |
| timing | No | Performance timing metrics |
| success | Yes | Whether the generation was successful |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses several important runtime behaviors: 30-60 second latency, streaming, a default of 4 images per prompt, configurable watermark/download defaults, and the return payload (URLs, local paths, performance timing). This is valuable context that annotations alone do not provide.
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 long but well-organized into clear sections: warning, primary use, args, returns, best practices, examples, and tips. The critical timeout warning is front-loaded at the very top, and each section earns its place by helping the agent craft better prompts and avoid pitfalls.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a generation tool of this complexity. It covers all parameters, the return format, the default behaviors, prompt guidance with examples, and the key environment-specific limitation. There is no obvious missing information an agent would need to call this tool successfully.
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 already covers all 6 parameters with 100% description coverage, so the baseline is 3. The description adds meaningful value above that by explaining prompt structuring (Subject + Action + Environment), style keywords, composition tips, text-in-image quoting, and concrete examples. This goes beyond simple parameter names and enum values.
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: generating images from a text description using SeeDream 4.5. It further positions it as 'the primary tool for creating images from scratch,' which distinguishes it from the edit/blend/variations siblings in the tool list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: it names the primary use case, warns that the tool times out on Claude.ai, and directs those users to seedream_submit with mode='text'. This gives the agent a concrete decision rule for choosing between this tool and a specific alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the health and status of the SeeDream MCP server.
Use this tool to verify the server is working correctly before generating images. This does NOT consume API quota - it's a free diagnostic check.
Args:
verbose (boolean): Include detailed system info (default: false)
Returns: Server health status, configuration check, and available tools.
Use when:
First connecting to verify everything is set up correctly
Troubleshooting when image generation fails
Checking if API key is configured properly
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | Include detailed system information |
| Name | Required | Description |
|---|---|---|
| status | Yes | Overall server status |
| platform | No | Operating system (verbose only) |
| memory_mb | No | Memory usage in MB (verbose only) |
| node_version | Yes | Node.js version |
| server_version | Yes | MCP server version |
| uptime_seconds | Yes | Process uptime in seconds |
| tools_available | Yes | List of available tools |
| firebase_user_id | No | Firebase user ID for image sync |
| api_key_configured | Yes | Whether ARK_API_KEY is set |
| firebase_configured | Yes | Whether Firebase sync is configured |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond those annotations: this is a free diagnostic that does not consume API quota and can verify API key configuration. This is meaningful behavioral detail for an agent deciding whether to call the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for purpose, usage, arguments, returns, and use cases. It is slightly longer than strictly necessary because the Args and Returns sections partially duplicate the schema and output schema, but each section still earns its place by reinforcing key operational details.
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 one-parameter, read-only, idempotent status tool with a full input schema and an output schema, the description covers all necessary context: purpose, when to use it, return contents, and quota behavior. An agent has everything it needs to select and invoke 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%, so the schema fully documents the single 'verbose' parameter. The description repeats the same information ('Include detailed system info (default: false)') without adding new semantic detail. Baseline 3 is appropriate because the schema already carries the parameter 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 a specific verb and resource: 'Check the health and status of the SeeDream MCP server.' It is immediately distinguishable from the image-generation siblings such as seedream_generate and seedream_edit, since this tool is a diagnostic health check rather than an image 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?
The description gives explicit 'Use when' scenarios including first connection, troubleshooting failed generation, and checking API key configuration. It also adds the useful note that the tool does not consume API quota. However, it does not explicitly state when not to use it or name alternative diagnostic tools, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit an image generation task. Returns immediately - images will appear in the Web App.
USE THIS TOOL ON CLAUDE.AI - The regular seedream_generate tool times out on Claude.ai. This tool returns immediately after submitting the task.
After submitting: View your generated images at https://seedream-gallery.firebaseapp.com
Args:
prompt (string, required): Description of the image to generate
mode (string): 'text' (default), 'image' (editing with 1 ref image), or 'multi' (blending 2+ images)
size (string): '2K' (default), '4K', '4K-9:16' (2304x4096), or aspect ratios: '1:1', '4:3', '3:4', '16:9', '9:16', '3:2', '2:3', '21:9'
count (number): Number of images to generate (1-15, default: 4)
strength (number): Reference strength 0-1 for image/multi modes (default: 0.7)
images (string[]): Reference image URLs for 'image' or 'multi' modes
Examples:
Text mode: { prompt: "A sunset over mountains", mode: "text" }
Image mode: { prompt: "Make this photo look like an oil painting", mode: "image", images: ["https://...jpg"] }
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Generation mode: 'text' for text-to-image, 'image' for editing (requires images), 'multi' for blending (requires 2+ images) | text |
| size | No | Output image size | 2K |
| count | No | Number of images to generate (1-15) | |
| images | No | Reference image URLs for 'image' mode (1 image) or 'multi' mode (2-14 images). Required when mode is not 'text'. | |
| prompt | Yes | Text description of the image to generate | |
| strength | No | Reference strength for image/multi modes (0-1, default 0.7) |
| Name | Required | Description |
|---|---|---|
| status | Yes | Task status: 'submitted' on success, 'error' on failure |
| message | Yes | Confirmation message or error description |
| success | Yes | Whether the task was submitted successfully |
| entry_id | Yes | Entry ID for internal tracking |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key async behavior: 'Returns immediately - images will appear in the Web App' and 'This tool returns immediately after submitting the task.' It also provides the specific gallery URL for viewing generated images. These are behavioral traits not captured by the annotations (readOnlyHint false, openWorldHint true), and they're critical for correct agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a bolded usage note, an 'Args' section, and examples. It is front-loaded with the most important facts (async return, usage on Claude.ai). Minor redundancy exists: 'Returns immediately' appears twice in nearly identical wording, and some param details duplicate the schema, but overall it remains readable and scannable.
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 6-parameter async submission tool, the description covers the key aspects: what it does, when to use it, async behavior, where to view results, modes, and examples. It doesn't explicitly mention checking status via seedream_status or what the response object contains, but the output schema exists to cover return values, and the web app URL addresses result retrieval. Complete enough 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%, so the baseline is 3. The description adds meaningful semantic detail beyond the schema: mode 'image' means 'editing with 1 ref image' and 'multi' means 'blending 2+ images'; '4K-9:16' is annotated as '2304x4096'; strength is described as 'Reference strength 0-1 for image/multi modes (default: 0.7)'. This gives the agent a clearer mental model of parameter relationships.
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 verb and resource: 'Submit an image generation task.' It immediately distinguishes itself from the regular seedream_generate tool by noting it returns immediately, so the agent knows this is the async-submit counterpart. The example modes (text/image/multi) also clarify the range of tasks it covers.
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 says 'USE THIS TOOL ON CLAUDE.AI' and explains why: 'The regular seedream_generate tool times out on Claude.ai.' This gives a direct when-to-use rule, a when-not-to-use rule, and names the alternative tool. It also tells the user where to view results after submission, which is practical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate multiple variations of an image concept using SeeDream 4.5.
⚠️ CLAUDE.AI USERS: This tool WILL TIMEOUT on Claude.ai (takes 30-90 seconds). Use "seedream_submit" instead for Claude.ai compatibility.
Use this tool to create 2-15 coherent variations based on a prompt. Great for:
A/B testing: Generate multiple options to compare
Storyboards: Create a series of related images
Product variations: Same product in different colors/styles
Exploration: See different interpretations of your concept
Social media: Multiple posts from one concept
Args:
prompt (string, required): Base concept for generating variations. Include batch keywords like "a series", "a set", "Generate X images" for best results.
count (number): Number of variations to generate (2-15, default: 4)
base_image (string, optional): Reference image to create variations from
size (string): Output size (default: '2K')
watermark (boolean): Add watermark (default: false)
download (boolean): Save locally (default: true)
download_dir (string): Local save directory
Returns: Array of variation image URLs, local paths if downloaded, and performance timing.
Prompt Best Practices (per official docs):
Include batch keywords: "a series of", "a set of", "Generate X images"
Describe variations explicitly: "4 seasonal versions", "different color schemes"
For storyboards: describe each panel's content in sequence
Keep prompts under 600 English words for best results
Examples:
"Generate a series of 4 seasonal variations of a cozy coffee shop interior"
"Create a set of 6 color variations of this minimalist logo design"
"Generate 4 different poses of this anime character in action"
"Create a 4-panel storyboard: morning coffee, commute, work, evening relaxation"
Tips:
The model maintains consistency across variations automatically
Use count=4 for quick comparisons, higher for more options
Adding a base_image helps maintain visual consistency
Note: base_image cannot be combined with batch generation (API limitation)
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Output image size | 2K |
| count | No | Number of variations to generate (2-15) | |
| prompt | Yes | Base prompt for generating variations. The model will create coherent variations based on this. | |
| download | No | Whether to download generated images to local directory | |
| watermark | No | Whether to add 'AI generated' watermark | |
| base_image | No | Optional base image to create variations from | |
| download_dir | No | Local directory to save images (defaults to ./generated_images) | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for structured data | markdown |
| Name | Required | Description |
|---|---|---|
| usage | No | API usage metrics |
| images | Yes | Array of generated images |
| prompt | Yes | The prompt used for generation |
| timing | No | Performance timing metrics |
| success | Yes | Whether the generation was successful |
| base_image | No | Base image used for variations |
| generated_count | Yes | Number of variations actually generated |
| requested_count | Yes | Number of variations requested |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical behavioral context beyond the sparse annotations: a 30-90 second timeout, the API limitation that 'base_image cannot be combined with batch generation,' and side effects like downloading locally, adding watermarks, and returning performance timing. These are exactly the behavioral traits an agent needs to predict runtime and side effects.
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 long but meticulously structured: a clear one-line purpose, a warning callout, bulleted use cases, an Args section with best practices, examples, and tips. The critical Claude.ai warning is front-loaded, and every section contributes actionable information, making the length justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers use cases, return values, prompt crafting, examples, API limitations, and platform compatibility. The input schema and output schema handle the remaining structured details; nothing an agent needs to select or invoke this tool 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 goes further with prompt best practices (batch keywords like 'a series of', explicit variation descriptions, under 600 words), count guidance (use 4 for quick comparisons), and a base_image caveat. This adds real value beyond the schema's one-line descriptions, though not every parameter gets the same depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Generate multiple variations of an image concept using SeeDream 4.5', a specific verb and resource that exactly matches the tool name and title. It clearly differentiates from siblings by emphasizing 'described variations' and 'coherent variations,' leaving no ambiguity about what this tool does versus seedream_generate, seedream_edit, or seedream_blend.
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?
It explicitly instructs 'Use this tool to create 2-15 coherent variations based on a prompt' and lists concrete use cases (A/B testing, storyboards, product variations, exploration, social media). It also includes a strong when-not directive with an explicit alternative: 'This tool WILL TIMEOUT on Claude.ai... Use seedream_submit instead.'
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.5.0seedream_blendseedream_editseedream_generateseedream_statusseedream_submitseedream_variationsScored across 6 tools
The core image tools are mostly distinguishable: generate creates from text, edit modifies a single image, blend combines multiple images, and variations makes coherent batches. However, seedream_submit duplicates generate/edit/blend behavior with only async execution as the differentiator, which creates real ambiguity about which tool an agent should select.
All tools share the consistent seedream_ prefix and mostly use verb-style suffixes (edit, generate, blend, submit). variations and status are noun suffixes, which is a minor deviation, but the overall pattern remains predictable and readable.
Six tools is a reasonable size for an image generation server, and most tools serve a distinct purpose. However, seedream_submit largely overlaps with the other image tools and exists primarily as a compatibility workaround, making the set feel slightly padded.
The server covers the main image workflows well: generation, editing, blending, variations, and health checking. The notable gap is that seedream_submit offers no MCP-based way to poll for results or retrieve submitted task outputs programmatically, forcing users to check an external web app.
Generate and edit images and create short videos inside Claude. Prepaid credits, no subscription.
Turn Claude into a creative studio: DNA-locked characters, images, video, voiceover — 55 tools.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
AI image and video generation, talking avatars, consistent characters and photo packs from Claude.
