Skip to main content

​
O modelo mental

O ComfyUI MCP é uma camada fina e bem descrita sobre uma instância do ComfyUI em execução. A maioria das ferramentas fala com essa instância pela API HTTP/WebSocket dela, então funcionam igual seja o ComfyUI local, remoto (--comfyui-url), ou Comfy Cloud (COMFYUI_API_KEY).
1

Geração e workflows → API HTTP do ComfyUI

generate_image, enqueue_workflow, fila/histórico/system-stats, e as ferramentas de autoria de workflow chamam /prompt, /queue, /history, /object_info etc. do ComfyUI. O enqueue é fire-and-forget: você recebe um prompt_id na hora e os resultados chegam por uma notificação de conclusão. No modo cloud, um cloud-client alternativo despacha as mesmas operações para cloud.comfy.org com X-API-Key.
2

Nós personalizados e modelos → ComfyUI-Manager (HTTP), com fallback de subprocesso

Instalar/atualizar/snapshot/bisect de nós e instalações de dependências de workflow preferem a API HTTP do ComfyUI-Manager (então também funcionam contra instâncias remotas), caindo para cm-cli / git / pip/uv contra uma instalação local quando a API não dá conta.
3

Instalação e operações de sistema de arquivos → só local

Instalar o ComfyUI, atualizar o núcleo, remover arquivos de modelo, ler logs do servidor e listar o diretório de saída operam no sistema de arquivos local. Exigem um COMFYUI_PATH conhecido e retornam um erro claro no modo remoto ou cloud.
4

WebSocket → local + remoto, não cloud

As notificações de conclusão de job se ligam ao WebSocket do ComfyUI quando disponível. O Comfy Cloud não tem WebSocket — o observador de jobs cai no caminho existente de sondagem HTTP.
Regra prática: qualquer coisa que lê ou executa o servidor conectado funciona em qualquer modo; qualquer coisa que instala software ou toca arquivos no disco precisa de uma instalação local. A matriz completa de paridade de recursos está em Configuração → Modos de implantação.

​
Autocura: o watchdog de fila/renderização

Um passo de sampler em alta resolução emperrado costumava deixar o agente empilhar jobs atrás de uma renderização zumbi que ele não conseguia ver nem matar. Três proteções de melhor esforço fecham essa lacuna, para o agente parar de reenfileirar às cegas atrás de uma renderização travada:
  • Contrapeso — panel_run acrescenta um QUEUE WARNING ao resultado quando uma renderização já está rodando, para o agente não empilhar atrás dela.
  • Detecção de stall — um WebSocket passivo para o ComfyUI acompanha o prompt / nó / progresso em execução; um passo que para de avançar além do limiar (COMFYUI_MCP_STALL_S, padrão 180s) prefixa uma nota de uma linha STALL/BACKLOG no próximo turno do agente.
  • Cancelamento em escalada — queue (action:“cancel”) interrompe, verifica se o job de fato parou (dentro de COMFYUI_MCP_INTERRUPT_S, padrão 30s), depois escala para /free e reporta a renderização WEDGED (sugerindo restart_comfyui) se ela ainda não morrer; clear_pending descarta todos os jobs pendentes na mesma chamada.
Tudo é fail-safe: se o WebSocket do watchdog nunca abre, nada muda. O agente também consegue raciocinar sobre as cores de uma imagem sem uma ida e volta de visão via get_image (action:"analyze_color") (paleta dominante, estatísticas de média + luminância, checagens de contraste).

​
Categorias de ferramentas

Geração de imagens

Execução de workflows

Autoria de workflows

Biblioteca de workflows

Assets e imagens

Modelos

Nós personalizados

Nós de API

Instalação e ambiente

Controle de processo

Padrões, estatísticas e skills

A Referência de ferramentas é gerada a partir dos schemas ao vivo das ferramentas MCP (npm run docs:gen), então nunca se descola do código.