SeedreamMCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.14
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
Six tools is well-scoped for an image generation and editing server. Each tool covers a necessary function without redundancy or bloat.
Completeness5/5
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.
Average 4.4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on August 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![SeedreamMCP MCP server](https://glama.ai/mcp/servers/AceDataCloud/SeedreamMCP/badges/card.svg)](https://glama.ai/mcp/servers/AceDataCloud/SeedreamMCP)

Score Badge

Copy to your README.md:

[![SeedreamMCP MCP server](https://glama.ai/mcp/servers/AceDataCloud/SeedreamMCP/badges/score.svg)](https://glama.ai/mcp/servers/AceDataCloud/SeedreamMCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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