The Image Generation MCP Server enables text-to-image generation and image upscaling via Stable Diffusion WebUI API.
Generate Images: Create images from text prompts with customizable parameters (sampling steps, dimensions, CFG scale, seed, sampler, batch size, etc.)
Upscale Images: Enhance image resolution using various upscaling models and modes (multiplier or dimensions)
Manage Models: List and switch between available Stable Diffusion models
Access Upscalers: Get available upscaler models for image enhancement
Advanced Controls: Adjust face restoration, tiling, negative prompts, and other image generation features
Provides text-to-image generation capabilities by connecting to a Stable Diffusion WebUI instance, allowing image generation, model selection, and image upscaling through the API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Image Generation MCP Server generate a fantasy landscape with mountains and a waterfall"
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.
A MCP server that provides text-to-image generation capabilities using Stable Diffusion WebUI API (ForgeUI/AUTOMATIC-1111).
Node.js
Access to a Stable Diffusion WebUI instance with API enabled
The WebUI must have --api flag enabled when starting
Clone the repository:
git clone https://github.com/Ichigo3766/image-gen-mcp.git
cd image-gen-mcpInstall dependencies:
npm installBuild the server:
npm run buildAdd the server configuration to your environment:
{
"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
}
}
}
}Replace the environment variables with your values:
SD_WEBUI_URL: URL of your Stable Diffusion WebUI instance
SD_AUTH_USER: Username for basic auth (if enabled)
SD_AUTH_PASS: Password for basic auth (if enabled)
SD_OUTPUT_DIR: Directory where generated images will be saved
SD_RESIZE_MODE: Default upscaling mode (0 for multiplier, 1 for dimensions)
SD_UPSCALE_MULTIPLIER: Default upscale multiplier when resize_mode is 0
SD_UPSCALE_WIDTH: Default target width when resize_mode is 1
SD_UPSCALE_HEIGHT: Default target height when resize_mode is 1
SD_UPSCALER_1: Default primary upscaler model
SD_UPSCALER_2: Default secondary upscaler model
Related MCP server: Image Generator MCP Server
generate_image - Generate images using Stable Diffusion
Parameters:
prompt (required): Text description of the desired image
negative_prompt: Things to exclude from the image
steps: Number of sampling steps (default: 4, range: 1-150)
width: Image width (default: 1024, range: 512-2048)
height: Image height (default: 1024, range: 512-2048)
cfg_scale: CFG scale (default: 1, range: 1-30)
sampler_name: Sampling algorithm (default: "Euler")
scheduler_name: Scheduler algorithm (default: "Simple")
seed: Random seed (-1 for random)
batch_size: Number of images to generate (default: 1, max: 4)
restore_faces: Enable face restoration
tiling: Generate tileable images
output_path: Custom output path for the generated image
get_sd_models - Get list of available Stable Diffusion models
No parameters required
Returns an array of model names
set_sd_model - Set the active Stable Diffusion model
Parameters:
model_name (required): Name of the model to set as active
get_sd_upscalers - Get list of available upscaler models
No parameters required
Returns an array of upscaler names
upscale_images - Upscale one or more images using Stable Diffusion
Parameters:
images (required): Array of image file paths to upscale
resize_mode: 0 for multiplier mode, 1 for dimension mode (default: from env)
upscaling_resize: Upscale multiplier when resize_mode=0 (default: from env)
upscaling_resize_w: Target width in pixels when resize_mode=1 (default: from env)
upscaling_resize_h: Target height in pixels when resize_mode=1 (default: from env)
upscaler_1: Primary upscaler model (default: from env)
upscaler_2: Secondary upscaler model (default: from env)
output_path: Custom output directory for upscaled images
For development with auto-rebuild:
npm run watchCommon issues and solutions:
Make sure your Stable Diffusion WebUI is running with the --api flag
Check if the WebUI URL is accessible from where you're running the MCP server
If using authentication, ensure credentials are correct
Verify the output directory exists and has write permissions
When upscaling, ensure the input image files exist and are readable
This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.
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. Dates show when Glama detected each change.
v1.0.0generate_imageget_sd_modelsget_sd_upscalersset_sd_modelupscale_imagesEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Qwen Image 3 AI image generation
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.
MCP server for Flux AI image generation
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Ichigo3766/image-gen-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
