Which integrations are available for this server?

Provides tools for generating and editing images through OpenAI-compatible image generation APIs, including the /images/generations and /images/edits endpoints, with support for text prompts, reference images, masks, and configurable output formats.

How do I use dsh-image-generate?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dsh-image-generate Generate an image of a cat wearing a spacesuit." 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.

dsh-image-generate

by smjda0719

Overview Schema Related Servers Score Discussions

Python

Remote

dsh-image-generate

面向 DeepSeek Harness（DSH）的图片 & 视频生成 MCP 服务器，工具接口对齐 OpenAI Images API 语义，后端接入阿里云百炼（DashScope）：

能力	模型	传输方式
文生图	`z-image-turbo`	DashScope 原生同步接口
文生图 / 图生图 / 图像编辑	`qwen-image-3.0`、`qwen-image-3.0-pro`	DashScope 原生同步接口（1-3 张参考图）
文生图 / 图生图 / 编辑	`qwen-image-3(-edit)` 及任意 OpenAI 兼容后端	OpenAI 兼容接口 `/images/generations`、`/images/edits`
文生视频 / 图生视频	`wan2.5` / `wan2.6` / `wan2.7` 系列	DashScope 异步任务（video-synthesis + 任务轮询）

生成结果自动下载到本地输出目录，同时返回远端 URL（有效期约 24 小时）与 local_path。

快速开始

# 1. 安装依赖（uv 会自动创建 .venv）
uv sync

# 2. 配置凭据（参考 .env.example）
Copy-Item .env.example .env   # 然后填入 DASHSCOPE_API_KEY
# 或在 ~/.dsh/.env 中配置，DSH 启动时会自动加载

# 3. 本地以 stdio 启动（MCP）
uv run dsh-image-generate --transport stdio

# 4. 或启动 streamable-http 服务（默认 127.0.0.1:8900/mcp）
uv run dsh-image-generate --transport streamable-http --port 8900

# 5. 跑测试
uv run pytest -q

# 6. 真实 API 冒烟测试（消耗少量额度，视频需数分钟）
uv run python scripts/smoke_test.py

Related MCP server: media-gen-mcp

MCP 工具

挂载到 DSH 后，模型看到的工具名为 mcp__dsh-image-generate__<工具名>。

`generate_image` — 文生图

参数语义对齐 OpenAI Images API：

参数	说明
`prompt`	提示词（中英文均可，必填）
`model`	默认 `z-image-turbo`；`qwen-image-3.0` / `qwen-image-3.0-pro` 或 OpenAI 兼容模型
`size`	`"1024x1024"`（OpenAI 写法，DashScope 下自动转为 `1024*1024`）
`n`	生成张数。z-image 每张单独调用；qwen-image-3.0 单次最多 6 张
`quality` / `style`	OpenAI 语义透传（DashScope 原生接口忽略）
`response_format`	`url`（默认）或 `b64_json`
`seed`	随机种子，用于结果复现
`negative_prompt`	反向提示词（仅 qwen-image-3.0 支持）
`prompt_extend`	提示词智能改写（改写结果会作为 `revised_prompt` 返回）
`watermark`	添加"AI 生成"水印（仅 qwen-image-3.0 支持）
`output_dir`	本地保存目录（相对路径相对于全局输出目录）

返回（OpenAI 风格 + 本地增强）：

{
  "created": 1789...,
  "provider": "dashscope-native",
  "model": "z-image-turbo",
  "data": [
    {"url": "https://.../xx.png", "revised_prompt": null,
     "local_path": "C:\\Users\\...\\outputs\\dsh-image-generate\\img-1-....png",
     "width": 1024, "height": 1024}
  ],
  "usage": {},
  "output_dir": "C:\\Users\\...\\outputs\\dsh-image-generate"
}

`edit_image` — 图生图 / 图像编辑

image（必填）+ 可选 image2、image3：本地路径 / http(s) URL / data: URL。
- DashScope 原生接口（qwen-image-3.0）：1-3 张参考图 + 编辑指令；
- OpenAI 兼容接口：上传为 /images/edits 的 multipart 文件。
mask：蒙版，仅 OpenAI 兼容后端支持（DashScope 原生接口会报错说明）。
strength：编辑强度，仅 OpenAI 兼容后端。
其余参数同 generate_image。

`generate_video` — 文生视频 / 图生视频（异步任务）

参数	说明
`prompt`	视频描述，支持分镜头写法（`第1个镜头... 第2个镜头...`）
`model`	默认 `wan2.6-t2v`；图生视频用 `wan2.5-i2v-preview` / `wan2.6-i2v`
`image`	图生视频的首帧图（本地路径 / URL / data: URL）
`duration`	2-15 秒
`size`	`"1280x720"`（wan2.5/2.6）；或 `resolution`（480P/720P/1080P）+ `ratio`（wan2.7）
`shot_type`	`multi` 多镜头（wan2.6+）
`wait`	默认 `true`：阻塞等待完成（数分钟）；`false` 立即返回 `task_id`
其余	`seed`、`negative_prompt`、`prompt_extend`、`watermark`

wait=true 超时或中断后，可用 get_video_status(task_id=...) 继续查询并下载。

`get_video_status`

查询视频任务状态；SUCCEEDED 时默认下载到本地并返回 local_path。任务 ID 24 小时内有效。

`list_models`

返回支持的模型目录、能力说明与当前默认配置。

配置（环境变量）

变量清单见 .env.example。关键项：

变量	默认	说明
`DASHSCOPE_API_KEY`	—	必填，百炼 API Key（可放 `.env`）
`IMG_DASHSCOPE_BASE_URL`	`https://dashscope.aliyuncs.com/api/v1`	DashScope 原生接口根
`IMG_OPENAI_BASE_URL`	`https://dashscope.aliyuncs.com/compatible-mode/v1`	OpenAI 兼容接口根
`IMG_OUTPUT_DIR`	`~/.dsh/outputs/dsh-image-generate`	输出目录
`IMG_DEFAULT_IMAGE_MODEL`	`z-image-turbo`	默认文生图模型
`IMG_DEFAULT_VIDEO_MODEL`	`wan2.6-t2v`	默认视频模型
`IMG_VIDEO_POLL_TIMEOUT`	`900`	视频任务最长等待（秒）

ℹ️ 命名说明：早期版本曾用 DSH_IMG_* 命名，但 Harness 的 dsh-app-boot 禁止任何 .env 文件声明 DSH_*、XDG_*、DYLD_*、BASH_FUNC_* 前缀及 PATH/HOME/HTTP_PROXY 等启动期变量（违者启动直接失败，报 "... which only the launching environment may set"）。因此本项目统一改用 IMG_* 前缀，.env 与导出环境变量两种方式都可用：

# 方式 A：写入 ~/.dsh/.env（IMG_* 不在保留名单内，安全；Harness 启动时自动加载）
#   DASHSCOPE_API_KEY=sk-xxx
#   IMG_DASHSCOPE_BASE_URL=https://dashscope.aliyuncs.com/api/v1
#   IMG_OPENAI_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1

# 方式 B：导出为系统/用户环境变量（DSH 进程重启后生效）
setx DASHSCOPE_API_KEY "sk-xxx"
setx IMG_DASHSCOPE_BASE_URL "https://dashscope.aliyuncs.com/api/v1"
setx IMG_OPENAI_BASE_URL "https://dashscope.aliyuncs.com/compatible-mode/v1"
setx IMG_OUTPUT_DIR "C:\Users\YOURNAME\.dsh\outputs\dsh-image-generate"

也可以把这些（非机密）值直接写成 cordis.patch.yml 中 MCP 行 env: 块的字面量。

业务空间（Workspace）专属域名（https://{WorkspaceId}.cn-beijing.maas.aliyuncs.com/...）同样受支持：把上述两个 BASE_URL 指向它即可，需保证 API Key 与域名同地域。

模型路由规则

已知 DashScope 原生模型（z-image-turbo、qwen-image-3.0*）→ 原生同步接口；
已知 OpenAI 兼容模型（qwen-image-3* 等）→ /images/generations、/images/edits；
其他模型名 → 走 IMG_DEFAULT_TRANSPORT（默认 dashscope-native）。

因此也可对接任意 OpenAI 兼容图片后端（包括自托管的 Z-Image OpenAI 兼容服务），只需设置 IMG_OPENAI_BASE_URL 与 IMG_OPENAI_API_KEY。

注意：部分业务空间（Workspace）专属域名的 compatible-mode 端点可能不提供 /images/generations 路由（实测返回 404）。此时请改用 DashScope 原生模型（z-image-turbo / qwen-image-3.0）或标准域名 https://dashscope.aliyuncs.com/compatible-mode/v1。

接入 DeepSeek Harness

在 $DSH_HOME/cordis.patch.yml（所有 profile 生效，热加载，无需重启）中插入：

- insert:
    - id: mcp-dsh-image-generate
      name: '@deepseek-ai/dsh-mcp-client'
      config:
        serverName: dsh-image-generate
        transport: stdio
        command: D:/py/dsh-imageGenerate/.venv/Scripts/dsh-image-generate.exe
        args: ['--transport', 'stdio']
        cwd: D:/py/dsh-imageGenerate
        env:
          DASHSCOPE_API_KEY: !!js process.env.DASHSCOPE_API_KEY
          IMG_DASHSCOPE_BASE_URL: !!js process.env.IMG_DASHSCOPE_BASE_URL
          IMG_OPENAI_BASE_URL: !!js process.env.IMG_OPENAI_BASE_URL
          IMG_OUTPUT_DIR: !!js process.env.IMG_OUTPUT_DIR
        failOnStartupError: true
        toolCallTimeoutMs: 900000   # 视频生成需数分钟

凭据与端点配置应导出为环境变量（setx，见上文"配置"一节）后由 !!js process.env.* 间接引用；不要把 IMG_* 写进任何 .env（DSH 启动层会拒绝启动），也不要在 cordis.patch.yml 里写字面量密钥（端点 URL 等非机密值可以写成 env 块字面量）。

项目结构

src/dsh_image_generate/
├── server.py                  # MCP 工具层（generate_image / edit_image / generate_video / ...）
├── config.py                  # 环境变量配置
├── storage.py                 # 下载落盘与 .meta.json
├── utils.py                   # size 语法、图片输入归一化等
└── providers/
    ├── openai_images.py       # OpenAI 兼容 transport（/images/generations、/images/edits）
    ├── dashscope_native.py    # DashScope 原生同步接口（z-image / qwen-image-3.0）
    └── dashscope_video.py     # DashScope 视频异步任务（提交 + 轮询）
tests/                         # 离线 mock 测试（httpx.MockTransport，无需 Key）
scripts/smoke_test.py          # 真实 API 冒烟测试

注意事项

费用：按生成张数/视频时长计费，n、duration 直接影响费用；测试建议 n=1。
URL 有效期：DashScope 返回的图片/视频 URL 仅保留 24 小时，务必使用返回的 local_path。
内容审核：违规提示词或输出会报 DataInspectionFailed / IPInfringementSuspect；提示词改写开启时可能引入版权内容触发审核，可关闭 prompt_extend 重试。
跨地域：模型、endpoint、API Key 必须同地域，否则鉴权失败。

开发

uv sync                # 安装依赖（含 dev）
uv run pytest -q       # 离线测试
uv run python scripts/smoke_test.py   # 真实 API 冒烟（需 Key 与额度）

Available Tools

5 tools

edit_imageA

图生图 / 图像编辑：基于 1-3 张参考图与编辑指令生成新图。

Args: image: 参考图（必填）。支持本地绝对/相对路径、http(s) URL 或 data: URL。 prompt: 编辑指令，描述期望的输出内容、风格与构图。 model: 模型名。默认 qwen-image-3.0；或 OpenAI 兼容的编辑模型（如 qwen-image-3-edit）。 image2, image3: 第 2、3 张参考图（DashScope 原生接口最多 3 张）。 mask: 蒙版图（仅 OpenAI 兼容 /images/edits 后端支持；DashScope 原生接口不支持）。 size: 输出分辨率，OpenAI 风格 "宽x高"；不填由模型自动推荐。 n: 生成张数。 response_format: "url" 或 "b64_json"。 seed: 随机种子。 negative_prompt: 反向提示词（qwen-image-3.0 支持）。 prompt_extend: 是否开启提示词智能改写。 watermark: 是否添加水印（仅 qwen-image-3.0 支持）。 strength: 编辑强度/与原图相似度（仅 OpenAI 兼容后端，可选）。 output_dir: 本地保存目录（相对路径相对于全局输出目录）。

ParametersJSON Schema

Name	Required	Default
`n`	No
`mask`	No
`seed`	No
`size`	No
`image`	Yes
`model`	No
`image2`	No
`image3`	No
`prompt`	Yes
`strength`	No
`watermark`	No
`output_dir`	No
`prompt_extend`	No
`negative_prompt`	No
`response_format`	No	url

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and performs admirably. It discloses backend-specific limitations (mask, strength, watermark support differences), supported input formats (local path/URL/data URL), model defaults, and the output_dir saving behavior. This is rich behavioral context beyond simple tool purpose.

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 organized as a concise bullet list with each parameter on one line, packed with essential information. The front-loading of the purpose sentence and the elimination of redundant wording make it efficient for the tool's complexity.

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 15 parameters, two backend modes, and an output schema, the description is comprehensive: it covers parameter semantics, backend limitations, defaults, and input formats. The output schema exists, so return-value details are not needed. This description is highly complete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates by explaining every parameter (all 15) and adding constraints and defaults not present in the schema, such as mask not being supported by DashScope native API, watermark only for qwen-image-3.0, and strength only for the OpenAI-compatible backend. This fully compensates for the lack of schema descriptions.

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 is an image-to-image / editing tool that generates new images from 1-3 reference images and edit instructions. It distinguishes itself from sibling tools like generate_image (likely text-to-image) and video tools by emphasizing the reference-image-based editing workflow.

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 provides clear context by specifying that it uses 1-3 reference images plus an edit prompt, which implies when to use it (when editing/reference images are available). However, it does not explicitly name alternatives or state when not to use it, such as when starting from text-only, which could be done with generate_image.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_imageA

文生图：根据文本提示词生成图片（参数语义对齐 OpenAI Images API）。

Args: prompt: 描述期望图像内容、风格与构图的提示词（中英文均可）。 model: 模型名。默认 z-image-turbo；可选 qwen-image-3.0 / qwen-image-3.0-pro，或任意 OpenAI 兼容后端模型（如 qwen-image-3）。 size: 输出分辨率，OpenAI 风格 "宽x高"（如 "1024x1024"），DashScope 下自动转换为 "宽*高"。 n: 生成张数（z-image 每张单独调用，qwen-image-3.0 单次最多 6 张）。 quality: 质量档位（OpenAI 语义；DashScope 原生接口忽略）。 style: 风格（OpenAI 语义；DashScope 原生接口忽略）。 response_format: "url" 返回远端 URL + 本地路径；"b64_json" 额外返回 base64 数据。 seed: 随机种子 [0, 2147483647]，用于结果复现。 negative_prompt: 反向提示词（qwen-image-3.0 支持；z-image 不支持）。 prompt_extend: 是否开启提示词智能改写（z-image/qwen 均支持，默认跟随模型侧默认值）。 watermark: 是否添加水印（仅 qwen-image-3.0 支持）。 output_dir: 本地保存目录（相对路径相对于全局输出目录）。 user: 透传给 OpenAI 兼容后端的 user 字段（可选）。

ParametersJSON Schema

Name	Required	Default
`n`	No
`seed`	No
`size`	No	1024x1024
`user`	No
`model`	No
`style`	No	natural
`prompt`	Yes
`quality`	No	standard
`watermark`	No
`output_dir`	No
`prompt_extend`	No
`negative_prompt`	No
`response_format`	No	url

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description takes on full responsibility and excels. It discloses model-specific behaviors (e.g., 'z-image 每张单独调用，qwen-image-3.0 单次最多 6 张'), parameter side effects ('quality 在 DashScope 原生接口忽略'), and output details ('url 返回远端 URL + 本地路径；b64_json 额外返回 base64 数据'), providing rich operational context.

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 front-loaded with a one-sentence summary, followed by a structured bullet list of parameter explanations. Despite its length, each entry provides necessary semantic detail for a 13-parameter tool, with no filler or redundant phrasing.

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's complexity (13 parameters, no annotations, no schema descriptions), the description is exceptionally complete. It covers all parameter behaviors, model differences, output formats, and local file saving, making it sufficient for an agent to select and invoke the tool correctly without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. Every parameter is explained with meaningful details: size format conversion ('宽x高' to '宽*高'), model options and defaults, support matrix for negative_prompt and watermark, and seed range [0, 2147483647]. This greatly exceeds the bare schema.

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 '文生图：根据文本提示词生成图片' (text-to-image: generate an image from a text prompt), which clearly states the tool's verb (generate) and resource (image). This distinguishes it from sibling tools like edit_image and generate_video, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the '文生图' (text-to-image) label, but there is no explicit guidance on when to choose this tool over alternatives like edit_image or generate_video. The description mentions '参数语义对齐 OpenAI Images API' but does not state exclusions or alternative tool references, so the agent must infer the appropriate context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_videoA

视频生成：文生视频或图生视频（DashScope 万相异步任务）。

生成耗时较长（通常 1-10 分钟）。默认阻塞等待完成；若超时或被中断，可用返回的 task_id 通过 get_video_status 继续查询。

Args: prompt: 视频内容描述（支持分镜头描述，如 "第1个镜头... 第2个镜头..."）。 model: 模型名。默认 wan2.6-t2v；图生视频用 wan2.5-i2v-preview / wan2.6-i2v 等。 image: 图生视频的首帧图片（本地路径 / URL / data: URL；文生视频留空）。 duration: 视频时长（秒），2-15 之间。 size: 分辨率 "宽x高"（如 "1280x720"，wan2.5/2.6 系列）。 resolution: 分辨率档位 480P/720P/1080P（wan2.7 系列）。 ratio: 画幅比例（如 "16:9"、"9:16"、"1:1"，wan2.7 系列）。 seed: 随机种子。 negative_prompt: 反向提示词。 prompt_extend: 是否开启提示词智能改写。 watermark: 是否添加水印（默认随模型）。 shot_type: 镜头类型（如 "multi" 多镜头，wan2.6 支持）。 wait: 是否阻塞等待任务完成（默认 true；false 立即返回 task_id）。 output_dir: 本地保存目录（相对路径相对于全局输出目录）。

ParametersJSON Schema

Name	Required	Description	Default
`seed`	No
`size`	No
`wait`	No
`image`	No
`model`	No
`ratio`	No
`prompt`	Yes
`duration`	No
`shot_type`	No
`watermark`	No
`output_dir`	No
`resolution`	No
`prompt_extend`	No
`negative_prompt`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full responsibility. It discloses the async nature, long generation time (1-10 minutes), blocking wait behavior, and the ability to continue via get_video_status. It does not mention rate limits or authentication, but core behavioral traits are well covered.

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 lengthy but well-structured: a brief summary, async behavior note, then a labeled Args list. Each parameter line is concise. No redundant fluff, though the length is justified given the number of parameters.

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?

For a complex tool with 14 parameters and multiple model families, the description covers the async workflow, parameter semantics, and the relationship with get_video_status. An output schema exists, so return format details are not required. Minor gaps around error handling or prerequisites, but overall complete enough for correct selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates by explaining every parameter's meaning, constraints (e.g., duration 2-15, size '1280x720'), and model-specific differences (wan2.5/2.6 vs 2.7). This is comprehensive and directly actionable, exceeding schema expectations.

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 explicitly states '视频生成：文生视频或图生视频', identifying the verb and resource clearly. It distinguishes from siblings like generate_image (image generation) and edit_image, and references get_video_status for querying, making the tool's scope unambiguous.

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 clear workflow guidance: default blocks until completion, and if timeout/interrupted, use get_video_status with the returned task_id. Parameter explanations also include context for choosing between text-to-video and image-to-video models. However, there is no explicit 'when not to use this tool' beyond inferring from alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_video_statusA

查询视频生成任务状态；任务完成时可选下载视频到本地。

Args: task_id: generate_video 返回的任务 ID（24 小时内有效）。 model: 生成时的模型名（仅用于记录，可不填）。 download: 任务成功时是否把视频下载到本地（默认 true）。 output_dir: 本地保存目录（相对路径相对于全局输出目录）。

ParametersJSON Schema

Name	Required	Description	Default
`model`	No
`task_id`	Yes
`download`	No
`output_dir`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses the download side-effect and default behavior, plus output_dir semantics, but does not explain whether the tool polls/waits for completion, returns immediate status, or how failures are handled.

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: a one-line summary followed by a focused Args list. Every sentence adds value, with no fluff or repetition.

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 moderate complexity and the presence of an output schema, the description adequately covers purpose, parameters, download behavior, and a key constraint (24h validity). It misses explicit polling/failure behavior, but is otherwise complete for a status-check tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description provides meaningful explanations for all 4 parameters: source and validity of task_id, optional model, download default true, and output_dir relative path semantics. This fully compensates for the bare schema.

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 the tool's function: '查询视频生成任务状态' (query video generation task status) with an optional download action. This specific verb-resource pair distinguishes it from sibling tools like generate_video and generate_image.

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 implies usage context through 'task_id: generate_video 返回的任务 ID' (task ID returned by generate_video), indicating this is a follow-up step after video generation. It also notes a 24-hour validity window, but does not explicitly mention alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_modelsA

列出本服务器支持的模型及其能力、默认模型与配置。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/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 of behavioral disclosure. It states the tool lists models and their attributes, implying a read-only operation, but does not explicitly declare side effects, access requirements, or other behavioral traits. It does add useful detail about the content returned (capabilities, default model, config).

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 a single, concise sentence with the action front-loaded. It contains no filler and earns its place by naming the exact scope and content.

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's simplicity (zero parameters, no nested objects, and an existing output schema), the description is complete. It covers all key aspects: what is listed, the server scope, and the type of information returned.

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?

There are zero parameters and the input schema is empty, so the description does not need to explain parameter semantics. The baseline for parameterless tools is 4, and the description provides a clear overview without needing to compensate for schema gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists models supported by the server along with capabilities, default model, and configuration. The verb 'list' and resource 'models' are specific, and the sibling tools are generation/video tools, making the purpose distinct. However, it does not explicitly mention how it differs from siblings, so it falls slightly short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given on when to use this tool versus alternatives. The context implies it is for checking available models before using generation tools, but there are no clear exclusions or comparisons provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Aug 17, 2026
- First observededit_image
- First observedgenerate_image
- First observedgenerate_video
- First observedget_video_status
- First observedlist_models

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct operation: text-to-image, image editing, model listing, video generation, and status query. The overlapping media types are clearly differentiated by purpose and parameters, leaving no ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (generate_image, edit_image, list_models, generate_video, get_video_status). The style is uniform and predictable across the set.

Tool Count5/5

With 5 tools covering image and video generation plus supporting operations, the count is well-scoped for the server's purpose. Each tool earns its place without redundancy or bloat.

Completeness4/5

The core workflows are covered: text-to-image, image editing, text/video-to-video, model listing, and async status polling. A minor gap is the absence of cancellation or task history management for video generation, but the essential lifecycle is present.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-qwen-imageOAuth
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1
mcp-hailuoOAuth
io.github.AceDataCloud
MCP server for Hailuo (MiniMax) AI video generation
AI & Machine Learning Image & Video Processing
21
Claude Imagine AOAuth
com.claudeimagine
Generate AI images and videos from any compatible MCP client.
AI & Machine Learning Image & Video Processing
82
mcp-wanOAuth
io.github.AceDataCloud
MCP server for Wan AI video generation
AI & Machine Learning Image & Video Processing
21

Related MCP Servers

jgkme/kilo-image-gen-mcp
Image & Video Processing AI & Machine Learning
jgkme
A
license
Not graded
quality
B
maintenance
MCP server for generating, editing, and processing images via multiple providers including Kilo, OpenRouter, OpenAI, and Gemini, with local tools for background removal, resizing, and cropping.
Updated 2 months ago (2026-07-07 14:48 UTC)
23
2
MIT
media-gen-mcp
Image & Video Processing Multimedia Processing AI & Machine Learning
strato-space
A
license
B
quality
D
maintenance
MCP server for generating and editing images using OpenAI, and creating videos using OpenAI Sora and Google Veo. Enables fetching media from URLs or disk with smart output placement.
Updated 7 months ago (2026-01-30 04:38 UTC)
14
28
9
MIT
jimeng_visual_generation
Image & Video Processing AI & Machine Learning
justForever17
A
license
A
quality
C
maintenance
MCP server for generating images and videos using Volcengine's Jimeng APIs, supporting text-to-image, image-to-image, multi-image fusion, text-to-video, and image-to-video.
Updated 6 days ago (2026-09-01 07:21 UTC)
3
1
MIT
nanobanana-mcp
AI & Machine Learning Image & Video Processing
superboolgithub
F
license
A
quality
D
maintenance
MCP server for AI image generation supporting text-to-image and image-to-image editing via any OpenAI-compatible service, with configurable models, aspect ratios, and sizes.
Updated 7 months ago (2026-02-01 14:44 UTC)
2
-

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/smjda0719/dsh-image-generate'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

dsh-image-generate

快速开始

MCP 工具

generate_image — 文生图

edit_image — 图生图 / 图像编辑

generate_video — 文生视频 / 图生视频（异步任务）

get_video_status

list_models

配置（环境变量）

模型路由规则

接入 DeepSeek Harness

项目结构

注意事项

开发

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`generate_image` — 文生图

`edit_image` — 图生图 / 图像编辑

`generate_video` — 文生视频 / 图生视频（异步任务）

`get_video_status`

`list_models`