Servidor MCP para Stable Diffusion WebUI Forge - Neo · Genera imágenes en tu propia GPU, desde cualquier agente de IA que hable MCP
Pídele a Claude — o a cualquier agente compatible con MCP — una imagen, y la genera en tu Forge Neo local. Lee qué checkpoint está cargado, deduce los parámetros de muestreo y el estilo de prompt que espera ese modelo, escribe el prompt y te devuelve el archivo.
Nunca tienes que dictar pasos, CFG o sampler a menos que quieras. Esos provienen de tu propia configuración: los ajustes de tu instancia, tus generaciones pasadas, los metadatos de tu checkpoint. Cuando algo no se puede determinar, pregunta en lugar de adivinar.
[!IMPORTANT] Forge Neo debe ejecutarse con
--api. No se instala nada en tu carpeta de Forge — ni extensión, ni nodo personalizado. El puente habla con la API REST que Forge ya expone.
Related MCP server: invokeai-mcp
Forge Neo | ejecutándose con |
Python | 3.10 o más reciente, en la máquina que ejecuta el agente |
Un cliente MCP | Claude Code, Claude Desktop, Cursor o cualquier otro que hable MCP |
Solo si Forge se ejecuta en otra máquina: acceso de red a él, y un recurso compartido de archivos si quieres resultados como rutas de archivo en lugar de base64.
Edita tu webui-user.bat (Windows) o webui-user.sh (Linux) y añade --api:
set COMMANDLINE_ARGS=--apiConserva las banderas que ya tenías — solo añade --api. Reinicia Forge.
Comprueba que funciona: abre
http://127.0.0.1:7860/docs. Si ves los endpoints/sdapi/v1/...listados, la API está activa.
pip install git+https://github.com/eduardoabreu81/forgeneo-mcpClaude Code
claude mcp add forgeneo -e FORGE_URL=http://127.0.0.1:7860 -- forgeneo-mcpClaude Desktop, Cursor o cualquier cliente con un mcp.json
{
"mcpServers": {
"forgeneo": {
"command": "forgeneo-mcp",
"env": { "FORGE_URL": "http://127.0.0.1:7860" }
}
}
}Reinicia tu cliente — los servidores MCP se cargan al inicio, así que las herramientas aparecen en una nueva sesión.
Todo es opcional excepto FORGE_URL, y eso solo si Forge no está en 127.0.0.1:7860.
Variable | Qué hace | Por defecto |
| Dónde está Forge |
|
|
| ninguno |
| Traduce las rutas de Forge a rutas que tu máquina pueda alcanzar | ninguno |
| Tu carpeta de salida, si no se puede encontrar automáticamente | automático |
| Segundos de espera en una solicitud |
|
| Cuántas imágenes recientes leer al aprender tus ajustes |
|
|
| desactivado |
| Dónde se recuerdan tus respuestas confirmadas |
|
No hay nada más que hacer — los valores por defecto lo cubren.
Inicia Forge con --listen --api, luego apunta el puente hacia él y mapea sus rutas:
claude mcp add forgeneo \
-e FORGE_URL=http://gpu-box:7860 \
-e FORGE_PATH_MAP='D:/forge-neo=//gpu-box/share/forge-neo' \
-- forgeneo-mcpFORGE_PATH_MAP se lee como cómo lo llama Forge = cómo lo llamas tú. Forge reporta rutas como D:\forge-neo\output\...; si accedes a esa misma carpeta como \\gpu-box\share\forge-neo\output\..., ese mapeo permite que el puente te entregue rutas de archivo en lugar de megabytes de base64.
Sin él, todo sigue funcionando — solo obtienes base64.
[!NOTE]
--listenexpone la API a tu red sin contraseña. Si eso importa donde estás, añade--api-auth usuario:contraseñaa Forge y configuraFORGE_AUTHpara que coincida.
Abre una nueva sesión y pídele a tu agente que verifique la conexión. Llama a capabilities e informa lo que encontró:
reachable true
counts checkpoints · loras · samplers · schedulers · modules
filesystem file paths (or: base64 — no readable output dir)
history how many past generations it could readTres cosas que vale la pena revisar:
filesystem: base64 — falta FORGE_PATH_MAP o es incorrecto. No es fatal, pero los resultados inflarán tu conversación.
history: 0 — no puede aprender de tu trabajo pasado. Normalmente la carpeta de salida es inaccesible, o Forge no guarda metadatos (ver Solución de problemas).
loras: 0 con LoRAs instalados — la lista de LoRAs de Forge está vacía; actualízala en la interfaz.
Solo pregunta. El agente se encarga del resto.
"una imagen de portada para un post sobre senderismo invernal"
Comprueba qué está cargado, ve si ese modelo prefiere prosa o etiquetas, escribe el prompt en consecuencia y genera.
"lo mismo pero en el estilo que uso para miniaturas"
Busca entre tus LoRAs, encuentra el que quieres decir, toma su palabra de activación y el peso que normalmente usas, y lo escribe en el prompt — visiblemente, para que puedas leer lo que se envió.
"cambia a mi modelo de retratos"
Carga ese checkpoint. Si pertenece a una arquitectura diferente, el VAE y el codificador de texto correspondientes vienen con él.
Otras cosas que vale la pena preguntar directamente:
"¿qué modelo está cargado y cómo debo hacerle el prompt?" — el perfil, en términos simples
"¿cuáles de mis LoRAs funcionan con este checkpoint?" — filtrado a los compatibles
"¿mi configuración de flux está completa?" — verifica el VAE y los codificadores de texto
"detente" — interrumpe una generación en curso
Tu agente las elige por sí mismo; la lista está aquí para que sepas qué puede hacer.
Herramienta | Propósito |
| Qué ofrece esta instancia y qué pudo leer el puente |
| El checkpoint cargado: parámetros, estilo de prompt, salud de módulos |
| Cómo espera este modelo que se le haga el prompt, con sus etiquetas de calidad |
| Busca tus LoRAs por nombre, etiqueta, palabra de activación o descripción |
| Todo sobre un LoRA, con un fragmento de prompt listo |
| Lista, carga o actualiza checkpoints |
| Si el VAE y los codificadores de texto cargados se adaptan a la arquitectura |
| De dónde proviene un módulo faltante — descarga solo si apruebas |
| Genera a partir de un prompt escrito, txt2img o img2img |
| Verifica, interrumpe o salta el trabajo en curso |
Dice que no puede alcanzar Forge
Confirma que Forge se está ejecutando con --api y que http://127.0.0.1:7860/docs lista los endpoints /sdapi/v1/. Si Forge está en otra máquina, también necesita --listen, y un firewall puede estar bloqueando.
Los resultados vuelven como base64 e inundan la conversación
Falta FORGE_PATH_MAP o no coincide. Compara la ruta que reporta Forge — visible en la información de cualquier generación — con la ruta que usas para acceder a la misma carpeta.
No conoce mis ajustes habituales
Aprende de tus imágenes pasadas, lo que requiere que Forge guarde los parámetros de generación. En Settings → Saving images, mantén habilitada la opción "Save text information about generation parameters as chunks to png files", o activa el archivo .txt adjunto. Sin ninguno, tus salidas no llevan parámetros y recurre a los valores por defecto de la arquitectura.
Sigue preguntando a qué linaje pertenece mi checkpoint SDXL Pony, Illustrious, Animagine y SDXL estándar son indistinguibles del archivo — mismos tensores, mismo preset, diferente vocabulario de prompt. Responde una vez; se recuerda por archivo y nunca se vuelve a preguntar.
Las imágenes se ven mal después de cambiar de arquitectura Pide una verificación de módulos. Forge recuerda el último VAE y codificador de texto seleccionados bajo cada preset, así que cargar un checkpoint mientras otro preset estaba activo puede dejar los incorrectos adjuntos. La verificación nombra lo que falta y si el archivo correcto ya está instalado.
Se rechazó una descarga por falta de espacio
Es deliberado — comprueba el espacio libre antes de comenzar en lugar de fallar varios gigabytes después. Libera algo de espacio, o elige una compilación más ligera como fp8_scaled en lugar de bf16.
Parámetros de muestreo que se ajustan al modelo. Tomados de tus propias generaciones pasadas cuando están disponibles, y de la configuración de tu instancia en caso contrario — no de una tabla en este repositorio.
El vocabulario de prompt correcto. Etiquetas de calidad donde ayudan, ninguna donde perjudican: añadir masterpiece, best quality a un modelo entrenado con subtítulos diluye el prompt en lugar de mejorarlo.
Tus LoRAs, buscables. Por nombre, etiqueta, palabra de activación o descripción, con los pesos que realmente usas. Nada se añade a un prompt sin mostrártelo.
Incertidumbre honesta. Cuando la evidencia se agota, lo dice y pregunta. Sin adivinanzas silenciosas.
Verificaciones de salud de módulos. Nota cuando un preset ha tomado el VAE o codificador de texto incorrecto, y señala la descarga oficial para cualquier cosa que falte.
Las notas sobre cómo se deriva cada respuesta viven en el código fuente, junto al código que la deriva.
Video (Wan) — Forge genera video mediante conteos de fotogramas en múltiplos de 4n+1 y codifica con ffmpeg, pero la API descarta la ruta resultante. Recoger desde el disco ya es como vuelven las imágenes, así que esto es principalmente plomería.
Metadatos EXIF — JPEG y WebP almacenan parámetros en EXIF cuando el archivo .txt está desactivado; esa combinación actualmente no produce historial.
Autenticación — FORGE_AUTH está implementado pero no se ha probado contra una instancia real de --api-auth.
Forge Neo por Haoming02 — la WebUI a la que este puente se conecta, y la wiki de Download Models detrás de la referencia de módulos
Autores de modelos que publican guías reales de prompting en sus tarjetas — la tabla de dialectos se construye a partir de esas, no de suposiciones
Model Context Protocol — el protocolo y el SDK de Python
CivitAI — endpoint público por hash utilizado por la búsqueda opcional
MIT — ver LICENSE
Hecho con ❤️ para la comunidad de Stable Diffusion
Reportar un error • Solicitar una función • Discusiones • ☕ Ko-fi
Report what this Forge instance offers: routes, counts, and which metadata sources are available. Call this first in a session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry the burden of behavioral disclosure. It states the tool reports information, which implies read-only, but it does not explicitly confirm the absence of side effects, nor mention any authentication, latency, or output-size implications of being called first in a session.
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?
Two sentences, no filler. The core function is stated first, and the usage instruction is a separate, front-loaded directive. 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?
For a zero-parameter tool with no output schema, the description covers what the agent receives and when to call. It stops short of describing the exact shape of the routes/counts/metadata-source data, but that level of detail is rarely needed before invoking a discovery tool.
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, so the baseline is 4 per the rubric. The description adds context about what the returned report covers, which is the relevant semantic information an agent needs.
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 uses a specific verb (Report) with a clear resource (Forge instance) and enumerates the exact content of the report (routes, counts, metadata sources). This distinguishes it from sibling tools like model_profile or generate, which are about particular resources rather than an instance-wide overview.
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?
Explicitly instructs to call this tool first in a session, giving an unambiguous trigger condition. Since no sibling serves an overview/discovery role, there is no alternative to contrast, and the instruction is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from an already-written prompt.
The prompt is sent verbatim: include any <lora:name:weight> yourself. With
use_profile_defaults on, missing sampling parameters are filled from what the
loaded model actually used before, so leave them unset unless you mean to
override. That includes shift (Forge's distilled_cfg_scale) and the
dimensions: leaving them at 0 takes the architecture's own values instead of
a generic default. Returns file paths when the output folder is readable.
Pass init_image (a local file path) to run img2img instead, where
denoising_strength controls how far the result may drift from it: around
0.3 keeps the composition, 0.75 reinterprets it freely. Edit-style and video
models expect values close to 1.0.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| shift | No | ||
| steps | No | ||
| width | No | ||
| height | No | ||
| prompt | Yes | ||
| cfg_scale | No | ||
| scheduler | No | ||
| batch_size | No | ||
| init_image | No | ||
| sampler_name | No | ||
| negative_prompt | No | ||
| denoising_strength | No | ||
| use_profile_defaults | No |
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 that the prompt is sent verbatim, requires manual LoRA syntax, explains that missing sampling parameters are filled from the model's actual history under use_profile_defaults, clarifies that shift and dimensions default to architecture-specific values when left unset, and discloses that return values are file paths only when the output folder is readable. It also details denoising_strength effects and the near-1.0 expectation for edit/video models. This is thorough and goes far beyond a bare statement of purpose.
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?
Three paragraphs, each with a distinct focus: purpose, prompt/profile defaults, and img2img specifics. Every sentence adds meaningful information. The core purpose is stated first, and the most critical caveat (verbatim prompt, LoRA) comes immediately after. There is no fluff or redundant phrasing.
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 complex 14-parameter tool with no output schema, this description covers the essential usage nuances: the verbatim prompt behavior, profile default handling, dimension/shift semantics, img2img initiation, and denoising strength guidance. It also notes the conditional return format. What is omitted (error cases, exact output object structure) is minor and not required for correct invocation. Given the tool's complexity, the description is impressively complete.
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?
Schema description coverage is 0%, so the description must explain the parameters. It does so selectively but effectively: it explains shift as Forge's distilled_cfg_scale, dimensions default to the architecture's own values, init_image switches to img2img, denoising_strength controls drift with concrete ranges, and use_profile_defaults influences whether other parameters are ignored. These are the non-obvious ones; standard parameters like steps, cfg_scale, and negative_prompt are left to the agent's prior knowledge, which is reasonable given their commonality.
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 opens with a specific verb+resource: 'Generate an image from an already-written prompt.' This clearly distinguishes it from all sibling tools (profiles, progress, loras, models, etc.), which are about model management and introspection, not generation. No ambiguity about what the tool does.
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?
While it doesn't explicitly name alternative tools, the context makes the intended use unambiguous: it is the image-generation tool. It does provide clear guidance on when to use img2img (pass init_image) versus text-to-image, and explains the behavior of use_profile_defaults to avoid overriding model-specific settings. This is sufficient routing for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail for one LoRA, including description, tags, past usage and a ready-to-paste prompt fragment with its trigger words.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of signaling behavior. It frames the tool as informational, which reasonably implies a read-only operation, and it lists concrete output facets such as description, tags, past usage, and a trigger-word prompt fragment. It stops short of explicitly stating 'does not modify anything,' but the risk of misinterpretation is low.
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?
One tight sentence with the core purpose front-loaded and the output components listed afterward. There is no filler, redundancy, or unnecessary detail.
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 simple one-parameter informational tool, the description conveys the return value and general scope, but it lacks parameter-format guidance and any routing cues relative to siblings. Since there is no output schema and no annotations, more explicit context about what to pass and when to use this tool would improve completeness.
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 schema has only the 'name' parameter with 0% description coverage, and the tool description does not explain what format 'name' should take (display name, key, path, etc.). The phrase 'for one LoRA' weakly implies the parameter identifies a LoRA, but that is not enough to confidently construct a valid argument without further inference.
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 identifies the operation as retrieving full detail for a single LoRA and enumerates the specific contents returned. It also differentiates from siblings like loras, which likely provide a list rather than deep per-item detail.
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 singular phrasing 'one LoRA' implies this is for focused lookup, and sibling tools like loras are the natural list counterpart, but no explicit when-to-use or when-not-to-use guidance is given. The agent must infer the routing from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search available LoRAs by name, title, tags, trigger words or description.
Only call this when the request actually calls for one (a named style,
character, or concept) — most generations need no LoRA at all. kind can be
"content" or "accelerator"; accelerators change the sampling regime rather
than the image, so adopting one means adjusting steps and CFG together.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| limit | No | ||
| query | No | ||
| verbose | No | ||
| base_model | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the behavior of accelerators vs. content LoRAs, noting that accelerators change the sampling regime. It does not mention whether the operation is read-only (though 'Search' implies it) or what the response format is. This leaves moderate gaps, so a 3 is fair.
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 two sentences and efficiently conveys the core purpose and usage. It front-loads the action and then adds contextual guidance. It is appropriately sized, though it could benefit from a bulleted list for parameters, but as-is it's concise and clear. Score 4.
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?
The tool has 5 parameters and no output schema. The description does not explain query, limit, verbose, or base_model, nor does it describe the response. It also assumes knowledge of what 'content' vs 'accelerator' means beyond the brief note. Overall, it leaves too much unspecified for a complete tool definition. Score 2.
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?
Schema description coverage is 0%, so the description must compensate. It explains the 'kind' parameter in detail but ignores query, limit, verbose, and base_model entirely. This is insufficient for a 5-parameter tool, so a 2 is warranted.
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 tool's function: 'Search available LoRAs by name, title, tags, trigger words or description.' It identifies the resource (LoRAs) and the action (search). However, it doesn't explicitly differentiate from sibling lora_info, though the search vs. info distinction is inferable. So a 4 is appropriate.
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 explicit guidance: 'Only call this when the request actually calls for one (a named style, character, or concept) — most generations need no LoRA at all.' This clearly indicates when to use and when not to, and also explains the kind parameter's role in choosing content vs. accelerator. It doesn't name alternative tools, but the guidance is decisive enough for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe the currently loaded checkpoint: architecture preset, whether it behaves as a turbo/distilled model, the sampling parameters that actually worked before, the expected prompt dialect, and whether its VAE and text encoder modules exist. Call before writing a prompt for an unfamiliar model.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It describes what the tool reports (content list) and frames it as a read-only describe operation, but it does not explicitly state that it has no side effects, nor does it describe the return format or possible failure cases (e.g., no checkpoint loaded). The content list implies a safe read, but explicit disclosure is absent, leaving a minor gap.
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, dense sentence that fronts the main action ('Describe the currently loaded checkpoint') and then lists specific attributes. It is concise but somewhat packed with details, which slightly reduces readability. Overall, it earns its place without wasted words, so a 4 is fitting.
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 no parameters and no output schema, the description must convey what the agent receives; it does so by enumerating the key components (architecture, distilled status, sampling parameters, prompt dialect, module existence). It also includes the usage timing. It lacks mention of error scenarios, but for a straightforward describe tool, the provided details are sufficient for correct invocation.
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 zero parameters and 100% schema coverage, so there is nothing to explain—the baseline for 0 parameters is 4. The description adds no parameter information because none exist, which is appropriate.
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 opens with the specific verb 'Describe' and the resource 'currently loaded checkpoint', then enumerates the exact content: architecture preset, turbo/distilled status, sampling parameters, prompt dialect, and module existence. This clearly differentiates it from siblings like models (which likely lists available models) or prompt_dialect (which covers only one aspect). The call-before-writing-prompt instruction reinforces its distinct role.
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 explicitly states when to call: 'Call before writing a prompt for an unfamiliar model.' This is a clear, actionable context. It does not explicitly list alternatives or exclusion conditions, but the tool's comprehensive nature and the directive make usage unambiguous, so a near-top score is warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or load checkpoints. action: "list" | "load" | "refresh".
Loading swaps the model for the whole instance, including any human using
the web UI at the same time, and takes several seconds — only do it when the
operator asked for that model. When the target belongs to a different
architecture, its preset, VAE and text encoder are switched with it, since
Forge would otherwise load it against whatever modules are selected now. The
architecture is inferred from two signals and only acted on when they agree;
pass preset to state it outright.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| limit | No | ||
| query | No | ||
| action | No | list | |
| preset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility for disclosing behavior. It reveals that loading swaps the model for the entire instance, affects web UI users, takes several seconds, and switches preset/VAE/text encoder under certain architecture conditions. This is unusually transparent for such a side-effectful operation.
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 compact and front-loaded with the key action enum. The longer paragraph earns its place by disclosing critical side effects and architectural behavior. No filler or repetition.
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?
The load path is thoroughly described, including side effects and architecture handling. However, the list and refresh paths are under-specified, and with no output schema and no annotations, the description does not clarify what the tool returns or how limit/query affect list results. This leaves meaningful gaps for an agent.
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?
Schema coverage is 0%, so the description must compensate. It explains action values ('list' | 'load' | 'refresh') and the purpose of preset, but it does not clarify what name, limit, or query do, which are essential for the list action. This is partial compensation for a low-coverage schema.
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 opens with 'List or load checkpoints,' which names a specific resource and action set. It clearly identifies the tool's scope, though it does not explicitly distinguish itself from sibling tools like model_profile or loras.
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 gives explicit when-to-use guidance for the load action: 'only do it when the operator asked for that model.' It also explains when to pass a preset. However, it gives no guidance for choosing list vs. refresh or for using any sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the VAE and text encoders loaded for an architecture against what it actually needs, and list installed files that could fill any gap.
Defaults to the active preset. Worth calling after switching architecture or when output looks wrong for no obvious reason: Forge records the last selection made under a preset, so loading a checkpoint while another preset was active can leave the wrong modules attached. Where the reference does not state a VAE, it says so instead of guessing — a wrong VAE degrades output without raising an error.
| Name | Required | Description | Default |
|---|---|---|---|
| preset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior. It discloses that it says when a VAE is not stated instead of guessing, and explains the preset behavior. It implies read-only operation by listing files and checking, which is transparent. No contradictions with annotations since none are provided.
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 compact yet information-dense. It leads with the main purpose, then usage triggers, and finally a behavioral note. Each sentence contributes to understanding without fluff, and it is not overly long.
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?
The description covers what, when, why, and what it returns (list of installed files). While no output schema is provided, listing files is enough for an agent to understand the output. The description also hints at edge cases (missing VAE) and the reasoning behind the need for this tool. It is complete for a simple one-parameter tool.
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?
Schema coverage is 0% and there is only one parameter, preset. The description explains that it defaults to the active preset, which gives meaningful context for the parameter beyond the schema's default value. This compensates for the lack of schema documentation, though it does not specify format or types beyond the default.
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 function: checking VAE and text encoders against architecture needs and listing installed files to fill gaps. It uses a specific verb (check) and resource (VAE and text encoders), and distinguishes itself from siblings like model_profile and module_download by focusing on module alignment, not profiling or downloading.
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?
It provides explicit scenarios for use: after switching architecture or when output looks wrong without obvious cause. It explains the underlying reason (preset selection recording) and gives a clear rationale for calling it. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find, and optionally fetch, a VAE or text encoder the architecture needs.
Called with no arguments it lists what the active preset is missing and
where each file comes from, downloading nothing. Downloading requires both a
label naming one entry and confirm=True, and the operator has to agree
first: these are multi-gigabyte files written into their models folder,
often across a network share.
Links come from the Forge Classic wiki's Download Models page. Where several builds exist — bf16, fp8_scaled, gguf — they are all offered, because which to take depends on the operator's hardware, not on a default worth hiding.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | ||
| preset | No | ||
| confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does so thoroughly: it discloses that no-args downloads nothing, that download writes multi-gigabyte files into the models folder often over a network share, that confirmation is mandatory, and that all model build variants are offered rather than a hidden default. This is strong side-effect and safety transparency.
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 front-loaded with the core purpose, then adds exactly the operational details needed to avoid unsafe calls. Each sentence carries information; there is no filler or restatement of the tool name.
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?
The no-annotation, no-output-schema context makes the description the only source of behavior, and it covers invocation modes, side effects, file source, and build choices. However, the `preset` parameter is left ambiguous, and there is no indication of the return/listing format beyond 'lists what is missing.'
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?
Schema description coverage is 0%, so the prose must explain the parameters. It explains `label` and `confirm` well, but never describes the `preset` parameter—it only mentions 'the active preset'—so one of three parameters remains semantically unexplained.
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 opening sentence names a specific action — find and optionally fetch — a concrete resource (VAE/text encoder) and a scoping context (what the architecture needs). The no-arguments behavior makes the tool's role unmistakable and sets it apart from siblings like module_check.
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 clearly distinguishes the safe no-argument listing mode from the mutating download mode and states the exact precondition (`label` plus `confirm=True`). It does not name an alternative sibling for other cases, so it misses the 'when-not/alternatives' bar for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check or stop the current generation. action: "status" | "interrupt" | "skip".
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It lists actions but does not explain the consequences of each—for example, what 'interrupt' or 'skip' actually do, whether they are reversible, or if they have side effects. The tool appears to be a mutation-capable (stop) operation, yet that is not clearly characterized.
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 very short and front-loaded: it states the action and immediately lists the values. No filler. It could be slightly more structured (e.g., separate lines for each action) but it remains efficient and readable.
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 output schema and no annotations, the description is inadequate. It does not explain what each action returns or does, lacks details about error handling, or expected output. An agent may not know whether 'status' returns a string, a JSON object, or whether 'interrupt' requires any confirmation. This is a notable gap for such a simple tool.
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 schema gives only a name and default for the 'action' parameter. The description compensates by enumerating the allowed values ('status' | 'interrupt' | 'skip'), which adds meaning beyond the schema. This fits the low schema coverage, so the description carries the semantic load effectively.
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 states a clear purpose: checking or stopping the current generation, and enumerates three specific actions. This is distinguishable from siblings like 'generate' or 'models' because it focuses on the lifecycle of generation. However, it does not explicitly name a sibling it is not, so it loses one point.
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 implies it relates to an ongoing generation but does not specify conditions, such as 'use after generate' or 'use to retrieve status.' No exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How the loaded checkpoint expects to be prompted, with its quality tags.
Returns the dialect (pony / illustrious / animagine / anima / sd15 / sdxl_base / natural), the quality prefix and negative baseline it needs, and where that conclusion came from. Quality tags are not decoration: an Illustrious prompt without them degrades, and a Flux prompt with them degrades too.
When the dialect comes back unknown — xl covers Pony, Illustrious and
stock SDXL, which share tensors and preset — ask the operator, then call
again with confirm set to their answer. It is cached by file hash and
never asked again.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden and does so thoroughly. It reveals caching by file hash, the ambiguous xl case covering multiple dialects, the need for operator confirmation, and the warning that quality tags meaningfully affect output. No hidden side effects or surprising behaviors are apparent.
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 front-loaded with purpose, then organized into return contents, operational warnings, ambiguity handling, and caching behavior. Every sentence contributes meaningful information without filler or repetition.
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?
With no output schema and no annotations, the description fully covers required return semantics: possible dialects, quality prefix, negative baseline, and provenance. It also explains the ambiguous result path, the confirm parameter, and the caching behavior, making the tool safely and correctly callable by an agent.
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 only exposes an optional string confirm with no description, and schema coverage is 0%. The description compensates by explaining that confirm should be set to the operator's answer when the dialect comes back unknown, tying the parameter to the ambiguity workflow. It does not explicitly enumerate valid confirm values, but the dialect list in the description implies the expected value space.
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 tool returns the prompting dialect of the loaded checkpoint, enumerates all dialect values, and names the return components: quality prefix, negative baseline, and source. It is distinct from sibling tools like model_profile because it focuses specifically on prompt expectations and quality tags.
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 gives clear context: use the tool to learn how the loaded checkpoint must be prompted, especially regarding quality tags. It also covers the conditional workflow when the dialect is unknown, telling the agent to ask the operator and call again with confirm. It does not explicitly name sibling alternatives or when not to use it, but the context is strong.
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.
v0.1.0capabilitiesgeneratelora_infolorasmodel_profilemodelsmodule_checkmodule_downloadprogressprompt_dialectScored across 10 tools
Tools are mostly distinct by resource and action—LoRA search vs detail, module check vs download, generation vs progress—but model_profile and prompt_dialect overlap on prompt dialect, and models/model_profile could be confused at a glance. The detailed descriptions mitigate most ambiguity.
Names consistently use lowercase snake_case and a readable resource-oriented style (loras, lora_info, models, module_check). Not all are verb_noun—generate is a bare verb and progress is ambiguous—so it is not a perfect 5, but there is no chaotic convention mixing.
Ten tools is well within the ideal 3–15 range and matches the server's scope: discovery, model/prompt/LoRA/module setup, generation, and progress control. No tool feels redundant or superfluous.
The surface covers the full generation workflow—model loading, profiling, prompt dialect, LoRA lookup, module diagnostics/download, generate, and progress monitoring. Minor gaps exist (no LoRA download/management, no explicit output/history listing), but they are not required for the core purpose.
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation
Remote MCP for RunComfy: ComfyUI deployments, hosted models, LoRA training. 31 tools.
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
Generate and edit images, video, voice, lip-sync and 3D models from your AI agent.
