How do I use mclans-image-mcp?

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., "@mclans-image-mcp generate an image of a serene lake at sunset" 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.

mclans-image-mcp

by YupegLV

Overview Schema Related Servers Score Discussions

JavaScript

Local

mclans-image-mcp

异步生图 MCP Server — 提交即忘，图片自动下载到本地。

配置 MCP

Claude Code

编辑 ~/.claude/settings.json：

{
  "mcpServers": {
    "mclans-image": {
      "command": "npx",
      "args": ["-y", "github:YupegLV/mclans-create-image-mcp"],
      "env": {
        "IMAGE_API_KEY": "sk-xxxxx"
      }
    }
  }
}

Claude Desktop

编辑配置文件：

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "mclans-image": {
      "command": "npx",
      "args": ["-y", "github:YupegLV/mclans-create-image-mcp"],
      "env": {
        "IMAGE_API_KEY": "sk-xxxxx"
      }
    }
  }
}

Cursor / VS Code

在设置中搜索 MCP，添加服务器配置：

{
  "mcp": {
    "servers": {
      "mclans-image": {
        "command": "npx",
        "args": ["-y", "github:YupegLV/mclans-create-image-mcp"],
        "env": {
          "IMAGE_API_KEY": "sk-xxxxx"
        }
      }
    }
  }
}

API Key 配置说明

方式	说明
环境变量 `IMAGE_API_KEY`	推荐，在 MCP 配置的 `env` 中传入
命令行参数	在 `args` 中添加 `--api-key=sk-xxxxx`
配置文件	手动创建 `~/.mclans-image-mcp/config.json`

首次通过环境变量或命令行参数启动后，配置会自动持久化到 ~/.mclans-image-mcp/config.json，后续无需重复配置。

如需自定义 API 地址，可添加环境变量 IMAGE_API_BASE_URL 或命令行参数 --api-base-url=https://your-api-url。

Available Tools

5 tools

check_taskA

查询生图任务的状态和结果。后台 Worker 会自动轮询远程服务器并下载图片，无需手动轮询。任务完成后返回本地图片路径

ParametersJSON Schema

Name	Required	Description	Default
`taskId`	Yes	任务 ID

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description discloses the tool is a read-only query operation and that results include a local image path. It does not mention side effects, rate limits, or authentication, but is fairly transparent for a query 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 three short sentences, front-loading the purpose. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks detail on response structure for in-progress states or errors. Since there is no output schema, more completeness would be helpful.

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% for the single parameter, so the description provides minimal added value beyond the schema. It does not elaborate on the task ID origin or format.

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 queries the status and results of an image generation task. It distinguishes from siblings that generate or list tasks, making it easy to select.

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 mentions that background worker auto-polls, so no manual polling is needed, which implies when to use this tool for checking results. However, it does not explicitly state when not to use it or provide alternatives.

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

generate_imageA

提交异步生图任务，后台 Worker 会自动轮询远程服务器并下载图片到本地。图片保存到 projectDir/outputSubdir/ 目录下（默认 mclans-image 子文件夹，可通过 outputSubdir 参数自定义）。任务提交后立即返回，生图通常需要 5-10 分钟。请询问用户：是需要我持续跟踪任务进度直到完成，还是提交后由系统自动处理、后续按需查询？

ParametersJSON Schema

Name	Required	Description
`prompt`	Yes	图片描述
`projectDir`	Yes	必填：当前项目根目录的绝对路径。请先执行 pwd 或 echo %cd% 获取当前工作目录，然后将结果填入此参数。图片将保存到该路径下的输出子文件夹中
`fileName`	Yes	必填：保存的文件名（不含扩展名），请根据图片内容取一个简短有意义的英文名，如 cute-cat、sunset-beach 等。多张图片时自动加后缀，如 cute-cat-1、cute-cat-2
`count`	No	生成图片数量，默认 4 张。多张图片时文件名自动加序号后缀，如 fileName-1、fileName-2
`outputSubdir`	No	输出子文件夹名称，默认为 mclans-image。图片将保存到 projectDir/outputSubdir/ 目录下。可根据项目需要自定义，如 images、assets、output 等

TDQS

A4.3/5.0

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 discloses the async nature, polling mechanism, save location, and typical generation time, which is sufficient for a generation tool.

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 fairly concise and well-structured, starting with the core function, then detailing saving directory, then typical duration, and ending with user interaction. The user question could be omitted for brevity, but it adds clarity for usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description covers the save path, naming, and async behavior, it does not mention the return value (likely a task ID) or error handling. Given no output schema, this is a gap that reduces completeness.

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 100%, but the description adds significant value beyond schema descriptions: it explains how to obtain projectDir, naming conventions, auto-suffix for multiple images, and subdirectory customization. This meets the high bar.

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 submits an async image generation task and specifies where images are saved. It is distinct from siblings like check_task and generate_video, as it focuses on generating images.

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 explains that the task is async and returns immediately, and advises asking the user about progress tracking. It does not explicitly state when not to use this tool, but provides good context for decision-making.

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

generate_turnaroundA

提交异步角色多视图生成任务，根据参考图片生成 2x2 网格（正面/侧面/背面/动作），保持角色一致性。图片保存到 projectDir/outputSubdir/ 目录下（默认 mclans-image 子文件夹，可通过 outputSubdir 参数自定义）。请询问用户：是需要我持续跟踪任务进度直到完成，还是提交后由系统自动处理、后续按需查询？

ParametersJSON Schema

Name	Required	Description
`prompt`	Yes	角色描述
`imagePath`	Yes	必填：参考图片的本地路径或远程 URL
`projectDir`	Yes	必填：当前项目根目录的绝对路径。请先执行 pwd 或 echo %cd% 获取当前工作目录，然后将结果填入此参数。图片将保存到该路径下的输出子文件夹中
`fileName`	Yes	必填：保存的文件名（不含扩展名），请根据角色内容取一个简短有意义的英文名，如 warrior-turnaround、girl-views 等
`outputSubdir`	No	输出子文件夹名称，默认为 mclans-image。图片将保存到 projectDir/outputSubdir/ 目录下。可根据项目需要自定义，如 images、assets、output 等

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description must carry behavioral disclosure. It discloses async nature, output directory, and consistency requirement, but omits details like error handling, authentication needs, or what constitutes success/failure.

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?

Two sentences front-load the purpose and output specifics. The second sentence adds crucial user-interaction guidance. No extraneous information.

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 an async task with no output schema, the description should explain the return value (presumably a task ID). It does not. However, it covers input, output directory, and user interaction, making it mostly complete.

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 schema already documents parameters. The description adds value by explaining the default subfolder, the purpose of fileName (meaningful name), and how to obtain projectDir (via pwd).

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 verb (submit async task), resource (turnaround view generation), and output (2x2 grid with front/side/back/action). It distinguishes from sibling tools like generate_image (single image) and generate_video by specifying multi-view output.

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 instruction for the agent to ask the user about tracking behavior, which aids in correct usage. Does not fully detail when to choose this over siblings, but the purpose differentiation is clear enough.

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

generate_videoA

提交异步视频生成任务，后台 Worker 会自动轮询远程服务器并下载视频到本地。视频保存到 projectDir/outputSubdir/ 目录下（默认 mclans-image 子文件夹，可通过 outputSubdir 参数自定义）。支持文生视频和图生视频。任务提交后立即返回，视频生成通常需要较长时间。请询问用户：是需要我持续跟踪任务进度直到完成，还是提交后由系统自动处理、后续按需查询？

ParametersJSON Schema

Name	Required	Description
`prompt`	Yes	视频内容描述
`projectDir`	Yes	必填：当前项目根目录的绝对路径。请先执行 pwd 或 echo %cd% 获取当前工作目录，然后将结果填入此参数。视频将保存到该路径下的输出子文件夹中
`fileName`	Yes	必填：保存的文件名（不含扩展名），请根据视频内容取一个简短有意义的英文名，如 cat-running、ocean-waves 等
`model`	No	视频生成模型：ltx（LTX-2.3，默认）或 wan（Wan2.2）
`imagePath`	No	参考图片的路径，传入则为图生视频，不传则为文生视频
`resolution`	No	视频分辨率，如 1024x576（默认）
`numFrames`	No	视频帧数，默认 33
`outputSubdir`	No	输出子文件夹名称，默认为 mclans-image。视频将保存到 projectDir/outputSubdir/ 目录下。可根据项目需要自定义，如 videos、assets、output 等

TDQS

A3.5/5.0

Behavior3/5

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

Discloses async polling, saving to projectDir, and support for text/image-to-video. With no annotations, this carries full burden, but it omits details like return value (task ID?), error handling, authentication, or failure behavior, leaving gaps.

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?

Description is a single concise paragraph that front-loads the main purpose, then details, then user guidance. It is appropriately sized but could be more structured (e.g., bullet points) for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers async nature, output path, modes, and user interaction. However, with 8 parameters, no output schema, and no annotations, it misses critical details like what the tool returns (task reference) and how to handle errors or check progress, making it only moderately complete.

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 covers all 8 parameters with descriptions (100% coverage). The description adds practical tips for projectDir (use pwd) and fileName (meaningful English name), and clarifies outputSubdir defaults and usage, enhancing usability beyond schema.

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 it submits an asynchronous video generation task that saves to local directory, and mentions text-to-video and image-to-video modes. However, it doesn't explicitly differentiate from sibling tools like generate_image, but the unique verb 'generate_video' and async nature suffice.

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?

Provides guidance on the async nature and instructs the agent to ask the user about tracking progress. However, it lacks explicit when-to-use vs. alternatives (e.g., generate_image) and does not mention limitations or prerequisites.

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

list_tasksC

列出所有生图任务，可按状态筛选

ParametersJSON Schema

Name	Required	Description	Default
`status`	No	按状态筛选

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether it is read-only, pagination, ordering, or any limitations. It only states basic functionality.

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 a single concise sentence that front-loads the main action. No wasted words, though it could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional parameter and no output schema, the description is adequate but lacks details like returned fields, ordering, or pagination. It is minimally sufficient.

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 schema coverage is 100% with one parameter, and the description merely restates the filtering capability. The parameter description in schema is already clear ('filter by status'), so no additional meaning is added.

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 verb 'list' and resource 'tasks' (image generation tasks), and mentions filtering by status. It distinguishes from sibling tools like generate_image (creation) and check_task (checking a specific task).

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives like check_task. The description implies listing all tasks but does not specify context or exclusions, leaving the agent to infer usage.

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 updatesv1.0.0Jun 13, 2026
- First observedcheck_task
- First observedgenerate_image
- First observedgenerate_turnaround
- First observedgenerate_video
- First observedlist_tasks

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: generating images, generating turnaround (multi-view), generating videos, checking task status, and listing tasks. There is no overlap or ambiguity.

Naming Consistency4/5

Tool names follow a consistent verb_noun pattern in snake_case (e.g., generate_image, check_task, list_tasks). The only minor deviation is 'generate_turnaround' where 'turnaround' is a specific noun, but still fits the pattern.

Tool Count5/5

5 tools is well-scoped for an image and video generation server. It covers submission (3 generation types), status checking, and listing, without being overwhelming or too sparse.

Completeness4/5

The tool surface covers core workflows: submit generation tasks (image, turnaround, video), check results, and list tasks. However, there are no tools for cancelling or deleting tasks, which are minor gaps.

Maintenance

ActivityMaintained

ResponsivenessSyncing

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

Claude Imagine AOAuth
com.claudeimagine
Generate AI images and videos from any compatible MCP client.
AI & Machine Learning Image & Video Processing
92
mcp-qwen-imageOAuth
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1
mcp-flux-proOAuth
io.github.AceDataCloud
MCP server for Flux AI image generation
Image & Video Processing Multimedia Processing
23
OpenAI Tools MCP Server B
ai.com.mcp
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Image & Video Processing Audio Processing Multimedia Processing
927

Related MCP Servers

Together AI Image MCP Server
Image & Video Processing Autonomous Agents
stefanskiasan
A
license
B
quality
D
maintenance
Enables the generation of images using Together AI's models through an MCP server, supporting customizable parameters such as model selection, image dimensions, and output directory.
Updated 2 years ago (2025-01-25 21:14 UTC)
1
7
MIT
Nano Banana MCP Server
Image & Video Processing Multimedia Processing
NH-5
F
license
B
quality
D
maintenance
An MCP server that enables image generation using Google's Gemini Nano Banana Pro model via the Google AI Studio API. Users can generate and save images locally by providing text prompts through MCP-compatible clients.
Updated 7 months ago (2026-02-20 02:42 UTC)
1
-
hyper-video-service
Image & Video Processing Multimedia Processing
twilson63
F
license
Not graded
quality
D
maintenance
MCP server for programmatic video generation. Send a prompt, get an MP4.
Updated 4 months ago (2026-05-16 03:14 UTC)
-
image-mcp
AI & Machine Learning Image & Video Processing
RuntimeAll
A
license
Not graded
quality
C
maintenance
MCP server for generating images via text-to-image and image-to-image using lk888 API, returning base64 PNG and metadata.
Updated 4 months ago (2026-05-18 09:50 UTC)
MIT

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/YupegLV/mclans-create-image-mcp'

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