Skip to main content

​
El modelo mental

ComfyUI MCP es una capa fina y bien descrita sobre una instancia de ComfyUI en ejecución. La mayoría de las herramientas hablan con esa instancia a través de su API HTTP/WebSocket, así que funcionan igual tanto si ComfyUI es local, remoto (--comfyui-url) o Comfy Cloud (COMFYUI_API_KEY).
1

Generación y flujos de trabajo → API HTTP de ComfyUI

generate_image, enqueue_workflow, cola/historial/stats del sistema, y las herramientas de autoría de flujos de trabajo llaman a /prompt, /queue, /history, /object_info, etc. de ComfyUI. Encolar es disparar-y-olvidar: recibes un prompt_id al momento y los resultados llegan mediante una notificación de finalización. En modo nube, un cloud-client alternativo despacha las mismas operaciones a cloud.comfy.org con X-API-Key.
2

Nodos personalizados y modelos → ComfyUI-Manager (HTTP), con un respaldo de subproceso

Instalar/actualizar/instantánea/bisección de nodos y las instalaciones de dependencias de flujos de trabajo prefieren la API HTTP de ComfyUI-Manager (así que también funcionan contra instancias remotas), con un respaldo a cm-cli / git / pip/uv contra una instalación local allí donde la API no puede hacer el trabajo.
3

Instalación y operaciones de sistema de archivos → solo local

Instalar ComfyUI, actualizar el núcleo, eliminar archivos de modelos, leer los registros del servidor y listar el directorio de salida operan sobre el sistema de archivos local. Exigen un COMFYUI_PATH conocido y devuelven un error claro en modo remoto o nube.
4

WebSocket → local + remoto, no nube

Las notificaciones de finalización de trabajo se enganchan al WebSocket de ComfyUI donde está disponible. Comfy Cloud no tiene WebSocket — el vigilante de trabajos cae a su camino existente de sondeo HTTP.
Regla práctica: todo lo que lee o ejecuta el servidor conectado funciona en cualquier modo; todo lo que instala software o toca archivos en disco necesita una instalación local. La matriz completa de paridad de funciones está en Configuración → Modos de despliegue.

​
Autorreparación: el watchdog de cola/render

Un paso de sampler de alta resolución atascado dejaba que el agente apilara trabajos detrás de un render zombi que no podía ver ni matar. Tres guardas de mejor esfuerzo cierran ese hueco, para que el agente deje de reencolar a ciegas detrás de un render atascado:
  • Contrapresión — panel_run añade un QUEUE WARNING a su resultado cuando ya hay un render en marcha, para que el agente no apile detrás.
  • Detección de atasco — un WebSocket pasivo hacia ComfyUI sigue el prompt / nodo / progreso en curso; un paso que deja de avanzar más allá del umbral (COMFYUI_MCP_STALL_S, 180 s por defecto) antepone una nota STALL/BACKLOG de una línea al siguiente turno del agente.
  • Cancelación que escala — queue (action:“cancel”) interrumpe, verifica que el trabajo se detuvo de verdad (dentro de COMFYUI_MCP_INTERRUPT_S, 30 s por defecto), luego escala a /free y reporta el render WEDGED (sugiriendo restart_comfyui) si sigue sin morir; clear_pending tira todos los trabajos pendientes en la misma llamada.
Todo es a prueba de fallos: si el WebSocket del watchdog nunca se abre, no cambia nada. El agente también puede razonar sobre los colores de una imagen sin un ida y vuelta de visión mediante get_image (action:"analyze_color") (paleta dominante, estadísticas de media + luminancia, comprobaciones de contraste).

​
Categorías de herramientas

Generación de imágenes

Ejecución de flujos de trabajo

Autoría de flujos de trabajo

Biblioteca de flujos de trabajo

Assets e imágenes

Modelos

Nodos personalizados

Nodos API

Instalación y entorno

Control de procesos

Valores por defecto, stats y skills

La referencia de herramientas se genera a partir de los esquemas de herramientas MCP en vivo (npm run docs:gen), así que nunca se desvía del código.