Un servidor MCP que proporciona capacidades de generación de texto a imagen mediante la API WebUI de difusión estable (ForgeUI/AUTOMATIC-1111).
Node.js
Acceso a una instancia de WebUI de Stable Diffusion con API habilitada
La interfaz web debe tener el indicador --api habilitado al iniciarse
Clonar el repositorio:
git clone https://github.com/Ichigo3766/image-gen-mcp.git
cd image-gen-mcpInstalar dependencias:
npm installConstruir el servidor:
npm run buildAgregue la configuración del servidor a su entorno:
{
"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
}
}
}
}Reemplace las variables de entorno con sus valores:
SD_WEBUI_URL : URL de su instancia de WebUI de Stable Diffusion
SD_AUTH_USER : Nombre de usuario para autenticación básica (si está habilitada)
SD_AUTH_PASS : Contraseña para autenticación básica (si está habilitada)
SD_OUTPUT_DIR : Directorio donde se guardarán las imágenes generadas
SD_RESIZE_MODE : Modo de aumento de escala predeterminado (0 para multiplicador, 1 para dimensiones)
SD_UPSCALE_MULTIPLIER : Multiplicador de aumento de escala predeterminado cuando resize_mode es 0
SD_UPSCALE_WIDTH : Ancho de destino predeterminado cuando resize_mode es 1
SD_UPSCALE_HEIGHT : Altura de destino predeterminada cuando resize_mode es 1
SD_UPSCALER_1 : Modelo de escalador principal predeterminado
SD_UPSCALER_2 : Modelo de escalador secundario predeterminado
Related MCP server: Image Generator MCP Server
generate_image - Genera imágenes usando difusión estable
Parámetros:
prompt (obligatorio): descripción de texto de la imagen deseada
negative_prompt : Cosas a excluir de la imagen
steps : Número de pasos de muestreo (predeterminado: 4, rango: 1-150)
width : Ancho de la imagen (predeterminado: 1024, rango: 512-2048)
height : Altura de la imagen (predeterminado: 1024, rango: 512-2048)
cfg_scale : escala CFG (predeterminado: 1, rango: 1-30)
sampler_name : Algoritmo de muestreo (predeterminado: "Euler")
scheduler_name : Algoritmo del programador (predeterminado: "Simple")
seed : semilla aleatoria (-1 para aleatorio)
batch_size : Número de imágenes a generar (predeterminado: 1, máximo: 4)
restore_faces : Habilitar la restauración de rostros
tiling : generar imágenes en mosaico
output_path : Ruta de salida personalizada para la imagen generada
get_sd_models - Obtener la lista de modelos de difusión estable disponibles
No se requieren parámetros
Devuelve una matriz de nombres de modelos
set_sd_model - Establece el modelo de difusión estable activo
Parámetros:
model_name (obligatorio): Nombre del modelo que se establecerá como activo
get_sd_upscalers - Obtener la lista de modelos de escalador disponibles
No se requieren parámetros
Devuelve una matriz de nombres de escaladores
upscale_images - Mejora la escala de una o más imágenes usando difusión estable
Parámetros:
images (obligatorio): Matriz de rutas de archivos de imágenes para ampliar
resize_mode : 0 para el modo multiplicador, 1 para el modo de dimensión (predeterminado: desde env)
upscaling_resize : Multiplicador de aumento de escala cuando resize_mode=0 (predeterminado: desde env)
upscaling_resize_w : Ancho objetivo en píxeles cuando resize_mode=1 (predeterminado: desde env)
upscaling_resize_h : Altura objetivo en píxeles cuando resize_mode=1 (predeterminado: desde env)
upscaler_1 : Modelo de escalador principal (predeterminado: del entorno)
upscaler_2 : Modelo de escalador secundario (predeterminado: del entorno)
output_path : Directorio de salida personalizado para imágenes escaladas
Para desarrollo con reconstrucción automática:
npm run watchProblemas comunes y soluciones:
Asegúrese de que su interfaz web de difusión estable se esté ejecutando con el indicador --api
Comprueba si la URL de la interfaz web es accesible desde donde estás ejecutando el servidor MCP
Si utiliza autenticación, asegúrese de que las credenciales sean correctas
Verifique que el directorio de salida exista y tenga permisos de escritura
Al ampliar, asegúrese de que los archivos de imagen de entrada existan y sean legibles
Este servidor MCP cuenta con la licencia MIT. Esto significa que puede usar, modificar y distribuir el software libremente, sujeto a los términos y condiciones de la licencia MIT. Para más detalles, consulte el archivo de LICENCIA en el repositorio del proyecto.
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.
