SeedreamMCP is an MCP server for AI image generation and editing using ByteDance's Seedream models via the AceDataCloud API.
Text-to-image generation — Create high-quality images from text prompts (English or Chinese) using multiple model versions (v5.0 flagship, v4.5, v4.0, v3.0)
Image editing — Modify existing images with AI: change backgrounds, apply style transfers (anime, watercolor, oil painting), alter attributes (hair color, clothing), perform virtual try-on, or compose objects into new scenes
Multi-resolution output — Choose from 1K, 2K, 3K, 4K, adaptive, or custom dimensions; output as JPEG or PNG (URL or base64)
Reproducible generation — Use a seed parameter with v3 models for consistent, recreatable results
Sequential & streaming generation — Generate related images in sequence or stream progressive delivery (v4.5/v4.0 models)
Web search-enhanced generation — Incorporate real-world context into image generation with the v5.0 model
Task management — Track status and retrieve results for single or multiple tasks by ID; support for async webhook callbacks
Model & size discovery — List all available Seedream models with capabilities, best use cases, and pricing, plus all supported resolution options
Provides access to ByteDance's Seedream models for AI image generation and editing, including text-to-image creation, style transfer, background modification, and virtual try-on capabilities.
A Model Context Protocol (MCP) server for AI image generation and editing using ByteDance's Seedream models through the AceDataCloud API.
Generate and edit AI images directly from Claude, VS Code, or any MCP-compatible client.
Text-to-Image Generation — Create high-quality images from text prompts (Chinese & English)
Image Editing — Modify existing images with AI (style transfer, background change, virtual try-on)
Multiple Models — Seedream v5.0 (flagship), v4.5, and v4.0
Multi-Resolution — 1K, 2K, 3K, 4K, and custom dimensions
Sequential Generation — Generate related images in sequence (v4.5/v4.0)
Streaming — Progressive image delivery (v4.5/v4.0)
Task Tracking — Monitor generation progress and retrieve results
Related MCP server: Doubao Image/Video Generation MCP Server
Tool | Description |
| Generate an AI image from a text prompt using ByteDance's Seedream model. |
| Edit or modify existing images using ByteDance's Seedream/SeedEdit model. |
| Query the status and result of a Seedream image generation or edit task. |
| Query multiple Seedream image tasks at once. |
| List all available Seedream models with their capabilities and pricing. |
| List all available image sizes and resolution options for Seedream. |
Sign up at AceDataCloud Platform
Go to the API documentation page
Click "Acquire" to get your API token
Copy the token for use below
AceDataCloud hosts a managed MCP server — no local installation required.
Endpoint: https://seedream.mcp.acedata.cloud/mcp
All requests require a Bearer token. Use the API token from Step 1.
Connect directly on Claude.ai with OAuth — no API token needed:
Go to Claude.ai Settings → Integrations → Add More
Enter the server URL: https://seedream.mcp.acedata.cloud/mcp
Complete the OAuth login flow
Start using the tools in your conversation
Add to your config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"seedream": {
"type": "streamable-http",
"url": "https://seedream.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to your MCP config (.cursor/mcp.json or .windsurf/mcp.json):
{
"mcpServers": {
"seedream": {
"type": "streamable-http",
"url": "https://seedream.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to your VS Code MCP config (.vscode/mcp.json):
{
"servers": {
"seedream": {
"type": "streamable-http",
"url": "https://seedream.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Or install the Ace Data Cloud MCP extension for VS Code, which registers the hosted MCP servers with one-click setup.
Go to Settings → Tools → AI Assistant → Model Context Protocol (MCP)
Click Add → HTTP
Paste:
{
"mcpServers": {
"seedream": {
"url": "https://seedream.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Claude Code supports MCP servers natively:
claude mcp add seedream --transport http https://seedream.mcp.acedata.cloud/mcp \
-h "Authorization: Bearer YOUR_API_TOKEN"Or add to your project's .mcp.json:
{
"mcpServers": {
"seedream": {
"type": "streamable-http",
"url": "https://seedream.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to Cline's MCP settings (.cline/mcp_settings.json):
{
"mcpServers": {
"seedream": {
"type": "streamable-http",
"url": "https://seedream.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to your MCP configuration:
{
"mcpServers": {
"seedream": {
"type": "streamable-http",
"url": "https://seedream.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to Roo Code MCP settings:
{
"mcpServers": {
"seedream": {
"type": "streamable-http",
"url": "https://seedream.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to .continue/config.yaml:
mcpServers:
- name: seedream
type: streamable-http
url: https://seedream.mcp.acedata.cloud/mcp
headers:
Authorization: "Bearer YOUR_API_TOKEN"Add to Zed's settings (~/.config/zed/settings.json):
{
"language_models": {
"mcp_servers": {
"seedream": {
"url": "https://seedream.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}
}# Health check (no auth required)
curl https://seedream.mcp.acedata.cloud/health
# MCP initialize
curl -X POST https://seedream.mcp.acedata.cloud/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'If you prefer to run the server on your own machine:
# Install from PyPI
pip install mcp-seedream-pro
# or
uvx mcp-seedream-pro
# Set your API token
export ACEDATACLOUD_API_TOKEN="your_token_here"
# Run (stdio mode for Claude Desktop / local clients)
mcp-seedream-pro
# Run (HTTP mode for remote access)
mcp-seedream-pro --transport http --port 8000{
"mcpServers": {
"seedream": {
"command": "uvx",
"args": ["mcp-seedream-pro"],
"env": {
"ACEDATACLOUD_API_TOKEN": "your_token_here"
}
}
}
}docker pull ghcr.io/acedatacloud/mcp-seedream-pro:latest
docker run -p 8000:8000 ghcr.io/acedatacloud/mcp-seedream-pro:latestClients connect with their own Bearer token — the server extracts the token from each request's Authorization header.
Tool | Description |
| Generate an image from a text prompt |
| Edit or modify existing images with AI |
Tool | Description |
| Query a single task status and result |
| Query multiple tasks at once |
Tool | Description |
| List available models with capabilities |
| List available image size options |
Model | Version | Type | Best For | Price |
| v5.0 Pro | Text-to-Image | Flagship single image, highest quality (no image sets/streaming/web search) | ~$0.044-0.088/image |
| v5.0 Lite | Text-to-Image | Best quality, latest flagship, web search | ~$0.040/image |
| v4.5 | Text-to-Image | Previous flagship, great quality | ~$0.037/image |
| v4.0 | Text-to-Image | Best value, most tasks | ~$0.030/image |
User: Create a photorealistic image of a cat in a garden
Claude: I'll generate that image for you.
[Calls seedream_generate_image with detailed prompt]
→ Returns task_id and image URLUser: Change the background of this photo to a beach
[Provides image URL]
Claude: I'll edit that image for you.
[Calls seedream_edit_image with image URL and edit description]User: 生成一幅中国山水画，有远山、流水和古松
Claude: 好的，我来为您生成这幅山水画。
[Calls seedream_generate_image with Chinese prompt]Variable | Description | Default |
| API token from AceDataCloud | Required |
| API base URL |
|
| OAuth client ID (hosted mode) | — |
| Platform base URL |
|
| Request timeout in seconds |
|
| Logging level |
|
mcp-seedream-pro --help
Options:
--version Show version
--transport Transport mode: stdio (default) or http
--port Port for HTTP transport (default: 8000)# Clone repository
git clone https://github.com/AceDataCloud/SeedreamMCP.git
cd SeedreamMCP
# Create virtual environment
python -m venv .venv
source .venv/bin/activate # or `.venv\Scripts\activate` on Windows
# Install with dev dependencies
pip install -e ".[dev,test]"# Run unit tests
pytest
# Run with coverage
pytest --cov=core --cov=tools
# Run integration tests (requires API token)
pytest -m integration# Format code
ruff format .
# Lint code
ruff check .
# Type check
mypy core tools main.py# Install build dependencies
pip install -e ".[release]"
# Build package
python -m build
# Upload to PyPI
twine upload dist/*SeedreamMCP/
├── core/ # Core modules
│ ├── __init__.py
│ ├── client.py # HTTP client for Seedream API
│ ├── config.py # Configuration management
│ ├── exceptions.py # Custom exceptions
│ ├── server.py # MCP server initialization
│ ├── types.py # Type definitions
│ └── utils.py # Utility functions
├── tools/ # MCP tool definitions
│ ├── __init__.py
│ ├── image_tools.py # Image generation/editing tools
│ ├── task_tools.py # Task query tools
│ └── info_tools.py # Model & size info tools
├── prompts/ # MCP prompt templates
│ └── __init__.py
├── tests/ # Test suite
│ ├── conftest.py
│ ├── test_config.py
│ └── test_utils.py
├── deploy/ # Deployment configs
│ ├── run.sh
│ └── production/
│ ├── deployment.yaml
│ ├── ingress.yaml
│ └── service.yaml
├── .github/ # GitHub Actions workflows
│ ├── dependabot.yml
│ └── workflows/
│ ├── ci.yaml
│ ├── claude.yml
│ ├── deploy.yaml
│ └── publish.yml
├── .env.example # Environment template
├── .gitignore
├── .ruff.toml # Ruff linter config
├── CHANGELOG.md
├── Dockerfile # Docker image for HTTP mode
├── docker-compose.yaml # Docker Compose config
├── LICENSE
├── main.py # Entry point
├── pyproject.toml # Project configuration
└── README.mdThis server wraps the AceDataCloud Seedream API:
Seedream Images API — Image generation and editing
Seedream Tasks API — Task queries
AI Art Creation — Generate stunning artwork, illustrations, and digital art
Product Photography — Create professional product scene compositions
Content Creation — Generate images for blogs, social media, marketing
Virtual Try-On — Visualize clothing on different models
Style Transfer — Transform photos into different art styles
Game Design — Concept art, character design, environment design
E-commerce — Product mockups, lifestyle shots, banner images
MIT License - see the LICENSE file for details.
Edit or modify existing images using ByteDance's Seedream/SeedEdit model.
This tool modifies existing images based on text instructions. It can change
styles, backgrounds, attributes, clothing, and more. Supports single or
multiple image inputs.
Use this when:
- You want to modify or transform an existing image
- You need to change style, background, colors, or attributes
- You want to apply artistic transformations (watercolor, oil painting, etc.)
- You need virtual try-on (clothing on person)
- You want to place objects in different scenes
Common use cases:
- Style transfer: "Convert to anime style", "Make it look like a pencil sketch"
- Background change: "Replace background with a sunset beach"
- Attribute edit: "Change hair color to blonde", "Add sunglasses"
- Virtual try-on: Provide person image + clothing image
- Scene composition: Place products in realistic environments
Returns:
JSON with task_id, trace_id, success status, and edited image data
including image URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Output image resolution. '1K' (default), '2K', '3K', or '4K'. | |
| image | Yes | List of image URLs or base64-encoded images to edit. Supports HTTP/HTTPS URLs (publicly accessible) or base64 format (data:image/png;base64,...). Each image must be under 10MB. | |
| model | No | Model to use for editing. Seedream 5.0 Pro, 5.0 Lite, 4.5, and 4.0 all support image editing when images are provided. | doubao-seedream-5-0-260128 |
| tools | No | Optional list of tool types for the model to use during editing. | |
| prompt | Yes | Description of the edit to perform on the image(s). Describe what changes you want. Example: 'Change the background to a beach scene', 'Make the person wear a red dress', 'Convert to watercolor painting style' | |
| stream | No | Stream pictures progressively when supported. | |
| watermark | No | Whether to add an AI-generated watermark. Default is true. | |
| callback_url | No | Optional webhook URL for async result notification. | |
| output_format | No | Output image format. 'jpeg' (default) or 'png'. | |
| response_format | No | Response format. 'url' (default) or 'b64_json'. | |
| optimize_prompt_options | No | Optional prompt optimization configuration. | |
| sequential_image_generation | No | Generate related images based on input. 'auto' enables it. | |
| sequential_image_generation_options | No | Tunable options for grouped image generation. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the tool modifies existing images, supports single or multiple inputs, and returns JSON with task_id, trace_id, success, and image URLs. However, it does not clarify whether results arrive asynchronously, whether polling seedream_get_task is required, rate limits, or other 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 well-structured with a lead sentence, 'Use this when' bullets, concrete examples, and a returns section. It is somewhat long and the 'Common use cases' block partially overlaps with the earlier bullets, but each section is readable and earns its place.
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 13-parameter schema, full parameter descriptions, and an output schema, the description covers the decision boundary, common workflows, and return payload well. The main gap is the implicit async/task lifecycle: task_id is mentioned but there is no guidance about polling seedream_get_task or using callback_url to retrieve final results.
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 value beyond the schema by supplying concrete prompt examples per use case, such as 'Convert to anime style' and 'Replace background with a sunset beach', and by clarifying virtual try-on image arrangement with 'person image + clothing image'.
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 'Edit or modify existing images using ByteDance's Seedream/SeedEdit model' and then lists concrete edit categories and use cases. This clearly identifies the verb, resource, and scope, and distinguishes it from siblings like seedream_generate_image by emphasizing 'existing images' as the input.
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 provides an explicit 'Use this when' bullet list covering style transfer, background changes, attribute edits, virtual try-on, and scene composition. It does not explicitly name a sibling alternative or state when not to use it, but the edit-vs-generate boundary is strongly implied by the repeated 'existing image' framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an AI image from a text prompt using ByteDance's Seedream model.
This tool creates high-quality images from text descriptions using ByteDance's
Seedream models (powered by Doubao). Supports multiple model versions with different
capabilities and quality levels.
Use this when:
- You want to generate a new image from scratch based on a text description
- You need high-quality AI-generated images (photos, illustrations, art)
- You want to create images with specific styles, compositions, or themes
Do NOT use this when:
- You want to edit or modify an existing image (use seedream_edit_image instead)
- You need to combine multiple images (use seedream_edit_image instead)
Model selection guide:
- v5.0 (doubao-seedream-5-0-260128): Latest flagship, highest quality
- v4.5 (doubao-seedream-4-5-251128): Previous flagship, great quality and detail
- v4.0 (doubao-seedream-4-0-250828): Stable and cost-effective, great for most tasks
Returns:
JSON with task_id, trace_id, success status, and generated image data
including image URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Output image resolution. '1K' (default), '2K', '3K', or '4K'. You can also specify custom dimensions like '1024x1024', '1280x720', etc. | |
| model | No | Model to use for generation. 'doubao-seedream-5-0-pro-260628' (v5.0 Pro, flagship single image, highest quality; no sequential generation, streaming, or web search). 'doubao-seedream-5-0-260128' (v5.0 Lite, latest flagship, sequential generation, streaming, web search). 'doubao-seedream-4-5-251128' (v4.5, previous flagship, great quality). 'doubao-seedream-4-0-250828' (v4.0, stable, best value). | doubao-seedream-5-0-260128 |
| tools | No | Optional list of tool types for the model to use during generation. Currently only 'web_search' is supported. Only supported by doubao-seedream-5-0-260128 (v5.0). | |
| prompt | Yes | Description of the image to generate. Be descriptive about subject, style, atmosphere, lighting, and composition. Supports both Chinese and English. Example: 'A photorealistic portrait of an astronaut on Mars, golden hour lighting, cinematic composition, ultra-detailed' | |
| stream | No | Stream all pictures progressively. Default is false. Only supports v4.5 and v4.0 models. | |
| watermark | No | Whether to add an AI-generated watermark. Default is true. | |
| callback_url | No | Optional webhook URL to receive the result asynchronously. The API will POST the result to this URL when complete. Must be publicly accessible. | |
| output_format | No | Output image format. 'jpeg' (default) or 'png'. | |
| response_format | No | Response format for the generated image. 'url' (default) returns a public image URL. 'b64_json' returns base64-encoded image data. | |
| optimize_prompt_options | No | Optional prompt optimization configuration. Supports `mode` with values 'standard' (higher quality, slower) or 'fast' (quicker, lower quality). Only supported on doubao-seedream-4.5 (standard mode only) and doubao-seedream-4.0. | |
| sequential_image_generation | No | Generate related images based on input. 'auto' enables it, 'disabled' (default) turns it off. Only supports v4.5 and v4.0 models. | |
| sequential_image_generation_options | No | Tunable options for grouped image generation. Only honored when `sequential_image_generation=auto`. Supports `max_images` (int, range [1, 15]). Only supported on doubao-seedream-4.5 and doubao-seedream-4.0. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description assumes full disclosure burden. It explains model selection trade-offs, returns JSON with task_id, trace_id, success status, and image URLs, and implies asynchronous behavior via callback_url and task_id. However, it omits details like cost, rate limits, or potential content moderation, so it falls short of a 5.
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, bullet points, and front-loaded purpose. Every sentence provides actionable guidance—the model guide, usage criteria, and return format all earn their place. No filler or tautology.
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 (12 params, rich schema) and lacking annotations, the description covers all critical aspects: what it does, when to use it, model selection, and return format. It doesn't discuss error handling or API limits, but the output schema and parameter descriptions fill many gaps, making it complete enough for reliable 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%, so baseline is 3. The description adds substantial value by providing a model selection guide with qualitative distinctions (e.g., 'latest flagship, highest quality', 'stable and cost-effective'), and gives a concrete prompt example. This goes beyond the schema's enum lists.
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 a clear, specific verb+resource statement: 'Generate an AI image from a text prompt using ByteDance's Seedream model.' It also explicitly distinguishes from sibling tool seedream_edit_image, making its purpose unambiguous.
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?
Provides explicit 'Use this when' and 'Do NOT use this when' sections, naming the alternative sibling (seedream_edit_image) for editing/combining images. This gives clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the status and result of a Seedream image generation or edit task.
Use this to check if a generation/edit is complete and retrieve the resulting
image URLs and metadata.
Use this when:
- You want to check if an image generation has completed
- You need to retrieve image URLs from a previous generation
- You want to get the full details of a generated/edited image
Returns:
Task status and image information including URLs, prompts, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The task ID returned from a generation or edit request. This is the 'task_id' field from any seedream_generate_image or seedream_edit_image tool response. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it returns status and image information, implying a read-only operation. With no annotations, the description carries the burden and does well, though it could explicitly state it is non-destructive.
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?
Concisely structured with bulleted usage scenarios and a return summary, though some minor repetition between the first line and the list.
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 an output schema present and a single required parameter, the description fully covers the tool's purpose and usage, leaving no 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?
Schema coverage is 100% and the description's parameter info duplicates the schema description, adding no new 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 it queries the status and result of a specific task, distinguishing it from sibling tools like seedream_generate_image and seedream_get_tasks_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?
Provides explicit use cases (checking completion, retrieving URLs, getting full details) but does not mention when not to use or compare to seedream_get_tasks_batch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query multiple Seedream image tasks at once.
Efficiently check the status of multiple tasks in a single request.
More efficient than calling seedream_get_task multiple times.
Use this when:
- You have multiple pending generations to check
- You want to get status of several images at once
- You're tracking a batch of generations
Returns:
Status and image information for all queried tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| task_ids | Yes | List of task IDs to query. Allows querying multiple tasks at once. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the operation as querying (read-only) and states it returns 'Status and image information'. It does not mention auth requirements or rate limits, but for a query tool, this is sufficient. Slightly more detail on the response format would improve, but overall transparent.
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 concise with a clear initial sentence, a bullet-style list for usage scenarios, and a returns section. No redundant information; every sentence adds value.
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 simplicity (1 parameter, no annotations, output schema exists), the description sufficiently covers purpose, usage, and returns. It doesn't explain output schema details, but that's acceptable as the schema itself is present. A hint about pagination or result format could improve, but not necessary.
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 a clear parameter description. The tool description adds context about efficiency and use cases but does not add new parameter semantics beyond what the schema provides. 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?
The description clearly states 'Query multiple Seedream image tasks at once' and distinguishes from the sibling tool 'seedream_get_task' by highlighting batch efficiency. The verb 'query' and resource 'tasks' are specific.
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?
Provides explicit when-to-use scenarios: 'when you have multiple pending generations', 'when you want to get status of several images at once', 'when tracking a batch'. Although not explicitly stating when not to use, it implies the alternative for single tasks (seedream_get_task).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Seedream models with their capabilities and pricing.
Use this when:
- User asks what models are available
- You need to help choose the right model for a task
- You want to compare model capabilities
Returns:
Formatted table of all Seedream models with descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it returns a formatted table with descriptions, implying no side effects. Does not mention authentication requirements or data freshness, but for a read-only listing tool it is adequately transparent.
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?
Concise: one line for purpose, bulleted use cases, and output format. No fluff. Well-structured and easy to scan.
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 zero parameters and an output schema exists, description is complete. Explains what models are listed and for what purpose. Does not need to explain return values since output schema covers that.
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?
No parameters in input schema. Description compensates by detailing what the output includes (capabilities, pricing, descriptions). Baseline 4 for zero-param tools where description adds meaningful output context.
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 lists all available Seedream models with capabilities and pricing. Specific verb 'list' and resource 'models'. Distinguishes from sibling tools which focus on editing, generating, or retrieving tasks.
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 lists three use cases: user asks about models, need to choose a model, want to compare capabilities. Does not mention when not to use, but that is not critical for a simple listing tool. No alternative tools suggested, but sibling tools are distinct in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available image sizes and resolution options for Seedream.
Use this when:
- User asks about available image sizes
- You need to help choose the right resolution
- You want to understand size options
Returns:
Formatted list of all size options with descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states it returns a 'formatted list of all size options with descriptions', which is sufficient for a simple read-only listing tool with no parameters. It does not disclose potential rate limits or side effects, but these are minimal for such a 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 concise, with a clear 'Use this when' section and a 'Returns' section. Every sentence adds value, and the structure is front-loaded with 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 tool has zero parameters and a simple list output, the description fully covers its purpose, usage context, and return value. The output schema exists, and the description notes the return format adequately.
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 tool has no parameters, and schema description coverage is 100%. Per guidelines, baseline is 3 when coverage is high. The description does not add any parameter semantics since there are none to explain.
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 a specific verb 'List' and resource 'image sizes and resolution options for Seedream'. It clearly distinguishes from sibling tools like seedream_generate_image and seedream_list_models.
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 includes a 'Use this when' section listing three clear scenarios. While it doesn't explicitly state when not to use it or mention alternatives, the guidelines are adequate for an agent to understand when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: listing models, listing sizes, generating images, editing images, and querying tasks (individually or in batch). Even get_task and get_tasks_batch are clearly differentiated by scope.
All tools follow a consistent seedream_verb_noun pattern, e.g., list_models, generate_image, edit_image, get_task. The naming is predictable and makes tool selection straightforward.
Six tools is well-scoped for an image generation and editing server. Each tool covers a necessary function without redundancy or bloat.
The tool surface covers the full lifecycle: discovery (models/sizes), creation (generate/edit), and result retrieval (single and batch). No obvious gaps for the stated domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate images, video, music, voice and 3D through one API. 30 tools, 200+ models.
Best Image and video generation: 20+ models (Kling, Seedance, Veo, NB, FLUX.2), OAuth, pay-per-use.
MCP server for ByteDance Seedance AI video generation
AI-native digital asset management: semantic search, generative image edits, and CDN delivery.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AceDataCloud/SeedreamMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
