Stable Diffusion WebUI API (ForgeUI/AUTOMATIC-1111) を使用してテキストから画像への生成機能を提供する MCP サーバー。
Node.js
API が有効になっている安定した Diffusion WebUI インスタンスへのアクセス
WebUIを起動するときには--apiフラグが有効になっている必要があります
リポジトリをクローンします。
git clone https://github.com/Ichigo3766/image-gen-mcp.git
cd image-gen-mcp依存関係をインストールします:
npm installサーバーを構築します。
npm run buildサーバー構成を環境に追加します。
{
"mcpServers": {
"image-gen": {
"command": "node",
"args": [
"/path/to/image-gen-mcp/build/index.js"
],
"env": {
"SD_WEBUI_URL": "http://your-sd-webui-url:7860",
"SD_AUTH_USER": "your-username", // Optional: if authentication is enabled
"SD_AUTH_PASS": "your-password", // Optional: if authentication is enabled
"SD_OUTPUT_DIR": "/path/to/output/directory",
"SD_RESIZE_MODE": "0", // Optional: upscaling mode (0=multiplier, 1=dimensions)
"SD_UPSCALE_MULTIPLIER": "4", // Optional: default upscale multiplier
"SD_UPSCALE_WIDTH": "512", // Optional: default upscale width
"SD_UPSCALE_HEIGHT": "512", // Optional: default upscale height
"SD_UPSCALER_1": "R-ESRGAN 4x+", // Optional: default primary upscaler
"SD_UPSCALER_2": "None" // Optional: default secondary upscaler
}
}
}
}環境変数を実際の値に置き換えます。
SD_WEBUI_URL : Stable Diffusion WebUIインスタンスのURL
SD_AUTH_USER : 基本認証のユーザー名（有効な場合）
SD_AUTH_PASS : 基本認証のパスワード（有効な場合）
SD_OUTPUT_DIR : 生成された画像が保存されるディレクトリ
SD_RESIZE_MODE : デフォルトのアップスケーリングモード（乗数は0、寸法は1）
SD_UPSCALE_MULTIPLIER : resize_mode が 0 の場合のデフォルトのアップスケール乗数
SD_UPSCALE_WIDTH : resize_mode が 1 の場合のデフォルトのターゲット幅
SD_UPSCALE_HEIGHT : resize_mode が 1 の場合のデフォルトのターゲットの高さ
SD_UPSCALER_1 : デフォルトのプライマリアップスケーラモデル
SD_UPSCALER_2 : デフォルトのセカンダリアップスケーラモデル
Related MCP server: Image Generator MCP Server
generate_image - 安定拡散法を使用して画像を生成する
パラメータ:
prompt （必須）: 希望する画像のテキスト説明
negative_prompt : 画像から除外するもの
steps ：サンプリングステップ数（デフォルト：4、範囲：1〜150）
width : 画像の幅（デフォルト: 1024、範囲: 512-2048）
height : 画像の高さ（デフォルト: 1024、範囲: 512-2048）
cfg_scale : CFGスケール（デフォルト: 1、範囲: 1-30）
sampler_name : サンプリングアルゴリズム（デフォルト: "Euler")
scheduler_name : スケジューラアルゴリズム（デフォルト: "Simple"）
seed : ランダムシード（ランダムの場合は -1）
batch_size : 生成する画像の数（デフォルト: 1、最大: 4）
restore_faces : 顔の復元を有効にする
tiling : タイル化可能な画像を生成する
output_path : 生成された画像のカスタム出力パス
get_sd_models - 利用可能な安定拡散モデルのリストを取得します
パラメータは必要ありません
モデル名の配列を返します
set_sd_model - アクティブな安定拡散モデルを設定する
パラメータ:
model_name (必須): アクティブに設定するモデルの名前
get_sd_upscalers - 利用可能なアップスケーラーモデルのリストを取得します
パラメータは必要ありません
アップスケーラー名の配列を返します
upscale_images - 安定拡散法を使用して1つまたは複数の画像を拡大します
パラメータ:
images （必須）: アップスケールする画像ファイルのパスの配列
resize_mode : 乗数モードの場合は 0、次元モードの場合は 1 (デフォルト: env から)
upscaling_resize : resize_mode=0 の場合のアップスケール乗数（デフォルト: env から）
upscaling_resize_w : resize_mode=1 の場合のターゲット幅（ピクセル単位）（デフォルト: env から）
upscaling_resize_h : resize_mode=1 の場合のターゲットの高さ（ピクセル単位）（デフォルト: env から）
upscaler_1 : プライマリアップスケーラーモデル（デフォルト: envから）
upscaler_2 : セカンダリアップスケーラモデル（デフォルト: envから）
output_path : アップスケールされた画像のカスタム出力ディレクトリ
自動リビルドを使用した開発の場合:
npm run watchよくある問題と解決策:
Stable Diffusion WebUIが--apiフラグ付きで実行されていることを確認してください
MCPサーバーを実行している場所からWebUI URLにアクセスできるかどうかを確認します。
認証を使用する場合は、資格情報が正しいことを確認してください
出力ディレクトリが存在し、書き込み権限があることを確認します
アップスケールする場合、入力画像ファイルが存在し、読み取り可能であることを確認してください。
このMCPサーバーはMITライセンスに基づいてライセンスされています。つまり、MITライセンスの条件に従って、ソフトウェアを自由に使用、改変、配布することができます。詳細については、プロジェクトリポジトリのLICENSEファイルをご覧ください。
Generate an image using Stable Diffusion
| Name | Required | Description | Default |
|---|---|---|---|
| batch_size | No | Number of images to generate (default: 1) | |
| cfg_scale | No | CFG scale (default: 1) | |
| distilled_cfg_scale | No | Distilled CFG scale (default: 3.5) | |
| height | No | Image height (default: 1024) | |
| negative_prompt | No | Things to exclude from the image | |
| output_path | No | Custom output path for the generated image | |
| prompt | Yes | The prompt describing the desired image | |
| restore_faces | No | Enable face restoration | |
| sampler_name | No | Sampling algorithm (default: Euler) | Euler |
| scheduler_name | No | Scheduler algorithm (default: Simple) | Simple |
| seed | No | Random seed (-1 for random) | |
| steps | No | Number of sampling steps (default: 4) | |
| tiling | No | Generate tileable images | |
| width | No | Image width (default: 1024) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic function. It doesn't cover critical aspects like whether this is a long-running operation, rate limits, authentication needs, output format (e.g., file paths or URLs), or error handling, leaving significant gaps for an AI agent.
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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly for an AI agent.
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 complexity of a 14-parameter image generation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, output handling, and usage context, failing to provide the completeness needed for effective tool invocation despite the rich input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing detailed documentation for all 14 parameters, including defaults and constraints. The description adds no additional parameter information beyond what the schema already covers, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate') and resource ('an image') with the specific method ('using Stable Diffusion'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'upscale_images' or 'set_sd_model', which would require explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'upscale_images' for enhancing existing images or 'set_sd_model' for configuring models. There's no mention of prerequisites, such as needing a model loaded via 'set_sd_model', leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of available Stable Diffusion models
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves a list but doesn't describe the return format (e.g., JSON array, model names/IDs), pagination, error conditions, or performance aspects (e.g., cached vs. live data). For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 a single, efficient sentence that directly conveys the tool's purpose with zero wasted words. It is appropriately sized for a simple list-retrieval tool and front-loaded with the essential information, making it easy to parse quickly.
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 low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It lacks details on the return format, which is critical for a list-fetching tool, and doesn't integrate with sibling tools (e.g., how the output relates to 'set_sd_model'). For a tool with no structured metadata, the description should do more to compensate.
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 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to compensate for any parameter gaps, so it meets the baseline expectation for a parameterless tool by clearly stating what it does without unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('list of available Stable Diffusion models'), making the purpose immediately understandable. It distinguishes from siblings like 'generate_image' (creation) and 'set_sd_model' (configuration), though it doesn't explicitly differentiate from 'get_sd_upscalers' (which fetches a different resource type).
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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether models need to be loaded first), relate to 'set_sd_model' for model selection, or specify scenarios where this list is needed (e.g., before generating images). The description is purely functional without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of available upscaler models
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't describe whether this is a read-only operation, whether it requires authentication, what format the list returns in, or any rate limits. The description only states what the tool does, not how it behaves.
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 a single, efficient sentence that communicates the essential purpose without any wasted words. It's appropriately sized for a simple list-retrieval tool and front-loads the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the list returns (array of strings? objects with metadata?), whether the list is filtered or complete, or how this tool relates to the sibling 'upscale_images' tool that presumably uses these models.
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 zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, which is correct for this parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get list') and resource ('available upscaler models'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_sd_models' or 'upscale_images', but the focus on 'upscaler models' provides reasonable implicit distinction.
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?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, timing considerations, or relationships to sibling tools like 'upscale_images' (which might use these models) or 'get_sd_models' (which appears to serve a similar purpose for different models).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the active Stable Diffusion model
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | Yes | Name of the model to set as active |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool sets the active model, implying a mutation operation, but doesn't describe any behavioral traits such as whether changes are persistent, if it requires specific permissions, potential side effects on other tools, or error conditions. This leaves significant gaps for an agent to understand how to use it safely and effectively.
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 a single, direct sentence with zero wasted words. It front-loads the essential information ('Set the active Stable Diffusion model'), making it highly efficient and easy to parse. Every word 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 tool's moderate complexity (a mutation operation with one parameter) and the absence of annotations and output schema, the description is minimally adequate. It states what the tool does but lacks context on behavior, usage, and relationships with sibling tools. Without annotations or output schema, more detail would be beneficial, but it meets a basic threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'model_name' clearly documented. The description adds no additional meaning beyond what the schema provides, such as examples of valid model names or constraints. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target resource ('active Stable Diffusion model'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its siblings like 'get_sd_models' or 'generate_image', which would require mentioning it's for configuration rather than generation or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing to know available models from 'get_sd_models'), exclusions, or how it relates to sibling tools like 'generate_image' (which might use the active model). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upscale one or more images using Stable Diffusion
| Name | Required | Description | Default |
|---|---|---|---|
| images | Yes | Array of image file paths to upscale | |
| output_path | No | Custom output directory for upscaled images | |
| resize_mode | No | 0 for multiplier mode (default), 1 for dimension mode | |
| upscaler_1 | No | Primary upscaler model (default: R-ESRGAN 4x+) | |
| upscaler_2 | No | Secondary upscaler model (default: None) | |
| upscaling_resize | No | Upscale multiplier (default: 4) - used when resize_mode is 0 | |
| upscaling_resize_h | No | Target height in pixels (default: 512) - used when resize_mode is 1 | |
| upscaling_resize_w | No | Target width in pixels (default: 512) - used when resize_mode is 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'upscales' images, implying a transformation that likely requires computational resources and may take time, but doesn't mention performance characteristics, rate limits, error handling, or what the output looks like (e.g., file paths, formats). This leaves significant gaps for an agent to understand the tool's behavior.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to quickly understand the core functionality.
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 complexity of an 8-parameter tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., paths to upscaled images, success status), error conditions, or behavioral traits like processing time. For a tool that performs image transformation, more context is needed to guide proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing detailed documentation for all 8 parameters. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting. However, it doesn't compensate with extra context like default behaviors or usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('upscale') and resource ('one or more images') with the method ('using Stable Diffusion'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this from sibling tools like 'generate_image' or 'get_sd_upscalers' which might be related to image generation or upscaler retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'generate_image' for creating new images or 'get_sd_upscalers' for listing available upscaler models, nor does it specify prerequisites such as having image files ready or when upscaling is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0generate_imageget_sd_modelsget_sd_upscalersset_sd_modelupscale_imagesScored across 5 tools
Each tool has a clearly distinct purpose with no overlap: generate_image creates images, get_sd_models and get_sd_upscalers retrieve lists, set_sd_model configures the active model, and upscale_images enhances existing images. The descriptions make it impossible to confuse these tools.
All tools follow a consistent verb_noun pattern with snake_case (e.g., generate_image, get_sd_models, set_sd_model). The naming is predictable and readable throughout the set.
With 5 tools, this is well-scoped for an image generation server, covering core workflows like generation, model management, and upscaling. Each tool earns its place without bloat or thin coverage.
The toolset covers key operations for image generation and enhancement, including model selection and upscaling. A minor gap exists in lacking tools for deleting or managing generated images, but agents can work around this for most use cases.
MCP server for Qwen Image 3 AI image generation
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
An MCP server that integrates with Discord to provide AI-powered features.
