Comfy MCP

Comfy MCP

Drive your own ComfyUI from Claude Code, Claude Desktop, Cursor, or any MCP-speaking AI agent — an MCP server built on comfy-cli.

Quickstart · Configure your client · Comfy Cloud MCP · Tools · Contributing

Looking for the cloud-hosted version? Comfy Cloud MCP is set up below — install it instead of this server, or alongside it.

What it does:

• 🖼️ Generate — run a workflow JSON (API-format or UI export), or go text-prompt → image in one call.
• ⏱️ Monitor jobs — submit async, then wait / watch / cancel, read the failure verdict, and collect the output files.
• 🎞️ Preview media — turn video into a contact sheet and audio into a waveform the agent can inspect.
• 🔍 Introspect your live install — search the nodes, models, and templates your ComfyUI actually has (custom nodes included), not a static catalog.
• 🧩 Build workflows — validate a graph, edit a template's slots, and fan one workflow into variants.
• ♻️ Manage ComfyUI — launch / stop / restart the server, tail its logs, and stage input assets.

Each tool shells out to the comfy command with --where local --json, parses comfy-cli's envelope/1 output, and returns it — comfy-cli is the engine, and by default everything targets the ComfyUI on your machine (127.0.0.1:8188).

Scope — local-first, not local-only. A few flows already reach beyond your machine: partner_generate runs hosted partner models (Flux / Ideogram / Kling / …) entirely on partner infrastructure — no local ComfyUI in the execution path — and partner-API nodes let a locally-executed workflow call those same hosted models, while COMFYUI_URL points the run/job tools at a ComfyUI on another machine you control.

This server vs. Comfy Cloud MCP. Two different servers, and running both is normal. This one is stdio: your client launches it as a subprocess on your own machine, and it drives the ComfyUI installed there (or one on another machine you control). Comfy Cloud MCP is a remote HTTP server at https://cloud.comfy.org/mcp that your client connects to over the network, and it executes workflows on Comfy Cloud GPUs — no local GPU, no ComfyUI install. Both authenticate: this one signs in to Comfy through comfy-cli (auth_login or COMFY_API_KEY), the cloud one through OAuth in your browser or a Comfy Cloud API key. Both can spend credits on partner models, so partner generation is not the dividing line — what this server has no path to is Comfy Cloud itself: no cloud-hosted execution, no cloud queue, no cross-session cloud batches. Every tool here shells out to comfy --where local. Pick by where you want the work to run, or install the cloud server too.

Status: beta. 41 tools; core loop validated end-to-end against a live local ComfyUI (server_info → run_workflow → fetch_outputs → PNG on disk). CI runs pytest + ruff on Python 3.10 and 3.14.

Quickstart

Four steps take you from a fresh install to your first generated image.

1. Install the pieces.

   pip install comfy-mcp "comfy-cli>=1.14.0"  # this server + the engine it wraps
   comfy install                              # create a ComfyUI workspace (skip if you have one)
   

   Both names, one command — on purpose. Installing comfy-mcp does not install comfy-cli: it is not a declared dependency of this package, because the server runs whichever comfy binary your PATH (or COMFY_BIN) resolves to, which is often not the environment you installed the server into. Declaring it would put a second copy in this venv that may not be the one your tools actually drive; the version that matters is checked at runtime instead, against the binary really being called. Skip it and the server still starts and completes the MCP handshake — every tool call then fails with "comfy not found on PATH", which is a missing engine, not a broken install.

   pip install comfy-mcp puts a comfy-mcp console script on your PATH; that command is what you point your AI client at in step 3. (A dedicated venv is fine — MCP clients may not see that venv's PATH, which is exactly what COMFY_BIN is for; see Prerequisites.) comfy-mcp --version confirms it landed — but don't run comfy-mcp itself to test it: it is a stdio server that talks MCP over stdin/stdout, so in a terminal it just waits and exits without printing anything. comfy-mcp --help says the same thing in one screen.

   To install from a checkout of this repo instead, run pip install . there (pip install -e . for a working copy) — the comfy-cli half is the same either way.

   Installed this server back when it was called comfy-local-mcp? Do Upgrading from comfy-local-mcp first — installing comfy-mcp alone will not clean up after the old name.

2. Launch ComfyUI and leave it running:

   comfy launch
   

3. Add the server to your client using the snippet for your client in Configure your AI client just below, then restart / reload it so the tools appear.

4. Ask your agent to run a workflow. For example:

   "Confirm my local ComfyUI is running, then run the workflow at ~/workflows/txt2img.json and show me the image."

   Under the hood the agent calls server_info to confirm ComfyUI is up, run_workflow to execute your workflow JSON (API-format or a UI export), and fetch_outputs to collect the result. No hand-authored workflow? Ask it to start from a template instead — it can search_templates, fetch_template to write a runnable JSON, and run that — and fetch_template tells it up front if your install can't run that template yet.

Where the images land. ComfyUI writes generated files into your ComfyUI workspace's output/ directory (part of the workspace comfy install created). On top of that, fetch_outputs(prompt_id, out_dir) copies a finished job's outputs into any directory you name — so telling the agent "save them to ./outputs" puts a copy right where you asked while the originals stay in the ComfyUI workspace.

For video or audio output, pass the downloaded file to preview_media. It asks comfy-cli to render a PNG contact sheet or waveform and returns that image inline, so the agent can inspect the result without trying to embed the original media file in the MCP response.

Upgrading from comfy-local-mcp

This server used to be called comfy-local-mcp. It was never published to PyPI under that name, so this only affects you if you installed it from a source checkout — but for those installs the rename is not something pip install . finishes on its own, because comfy-mcp is a different distribution, not a new version of the old one. Four things moved:

Was	Is now
distribution / import package comfy-local-mcp / comfy_local_mcp	comfy-mcp / comfy_mcp
console script comfy-local-mcp (the "command" in your client config)	comfy-mcp
env var COMFY_LOCAL_MCP_DEBUG_LOG	COMFY_MCP_DEBUG_LOG
failure-log directory leaf comfy-local-mcp/	comfy-mcp/

1. Uninstall the old distribution first. Installing the new one leaves the old one in place, and its comfy-local-mcp script stays on your PATH pointing at a package that no longer exists — so an "upgraded" environment either keeps running the old code or fails with ModuleNotFoundError:

   pip uninstall comfy-local-mcp   # then: pip install comfy-mcp   (or `pip install -e .`)
   

2. Change "command" to comfy-mcp in every MCP client config that starts this server (.mcp.json, claude_desktop_config.json, ~/.cursor/mcp.json — see Configure your AI client), then restart the client. The old command name is gone; nothing aliases it.

3. Rename the failure-log env var if you set it. COMFY_LOCAL_MCP_DEBUG_LOG is no longer read, and an env block that still sets it logs nothing — a disabled log and a stale variable look identical from the outside. Use COMFY_MCP_DEBUG_LOG; see Failure log (opt-in).

4. Move an existing failure log if you're mid-investigation. The default path's directory leaf changed with the package, so a fresh run starts an empty failures.jsonl rather than appending to the trail you were collecting. Nothing reads the old directory any more — copy it across, or delete it:

   # macOS; ~/AppData/Local on Windows, ~/.config on Linux
   cd ~/Library/Application\ Support
   mkdir -p comfy-mcp
   mv comfy-local-mcp/failures.jsonl* comfy-mcp/ && rmdir comfy-local-mcp
   

   The glob carries the two rotations (failures.jsonl.1, failures.jsonl.2) along with the live file, and mkdir -p first means this is also safe once the new directory exists.

Configure your AI client

All three clients speak the same MCP stdio contract: run the comfy-mcp command as a server. Pick your client.

The server key (comfy-mcp in every snippet below) is just the label your client files these tools under — it is yours to choose, and the "command" (comfy-mcp) is the only part that has to match the installed console script. Earlier versions of this README used comfy-local, so if your config already has a comfy-local entry, edit it rather than pasting a second one — two keys pointing at the same command register the server twice and your client shows every tool twice. Keeping the old key is equally fine; nothing reads it.

The COMFY_BIN env entry is shown in every example. Drop it if comfy is already on the environment your client launches the server with; keep it (pointing at the absolute path) if it isn't. COMFY_API_KEY is also shown, commented as optional — keep it only if you use partner-API nodes (Seedream / Veo / Kling / Gemini / …); drop it otherwise.

On macOS, keep ComfyUI out of ~/Documents, ~/Desktop and ~/Downloads — or grant your client Full Disk Access. macOS blocks apps (and everything they launch) from reading those folders, so an install there fails with Operation not permitted before anything runs. See Troubleshooting.

Claude Code

One command registers the server:

# COMFY_API_KEY is optional — add it only if you use partner-API nodes
# (see the Partner-API nodes section).
claude mcp add comfy-mcp \
  -e COMFY_BIN=/path/to/venv/bin/comfy \
  -e COMFY_API_KEY=<your-comfy-api-key> \
  -- comfy-mcp

Or, to check it into a project, add a .mcp.json at the repo root:

{
  "mcpServers": {
    "comfy-mcp": {
      "command": "comfy-mcp",
      "env": {
        "COMFY_BIN": "/path/to/venv/bin/comfy",
        "COMFY_API_KEY": "<your-comfy-api-key>"
      }
    }
  }
}

Claude Desktop

Edit claude_desktop_config.json (Settings → Developer → Edit Config; on macOS it lives at ~/Library/Application Support/Claude/claude_desktop_config.json) and add the server, then restart Claude Desktop:

{
  "mcpServers": {
    "comfy-mcp": {
      "command": "comfy-mcp",
      "env": {
        "COMFY_BIN": "/path/to/venv/bin/comfy",
        "COMFY_API_KEY": "<your-comfy-api-key>"
      }
    }
  }
}

Cursor

Add the server to ~/.cursor/mcp.json (global) or .cursor/mcp.json in a project:

{
  "mcpServers": {
    "comfy-mcp": {
      "command": "comfy-mcp",
      "env": {
        "COMFY_BIN": "/path/to/venv/bin/comfy",
        "COMFY_API_KEY": "<your-comfy-api-key>"
      }
    }
  }
}

Comfy Cloud MCP

Everything above sets up this server, which runs on your machine. Comfy also runs a hosted MCP server — Comfy Cloud MCP — and it is a good fit when the machine can't carry local diffusion, or when you'd rather not install ComfyUI at all. It lives at:

https://cloud.comfy.org/mcp

Your client connects to that URL over remote HTTP (no subprocess, nothing to pip install) and workflows execute on Comfy Cloud GPUs. You need a Comfy Cloud account — sign up first if you don't have one, since the sign-in below uses it.

Two ways to authenticate. OAuth is the default: your client opens a browser, you pick a workspace, and tokens refresh themselves. For clients that don't speak MCP OAuth (Cursor today) and for headless/CI use, create a Comfy Cloud API key at platform.comfy.org/profile/api-keys — it starts with comfyui- — and pass it as an X-API-Key header. Prefer your client's env interpolation (${env:COMFY_API_KEY}) over pasting a key into a file you might commit.

Note that this is a separate credential path from the COMFY_API_KEY this server's own examples show: that one is read by comfy-cli on this machine for partner-API nodes. The same key works for both, but each server is configured on its own.

Claude Code (cloud)

Install the comfy-cloud plugin — it registers the MCP connection and adds /comfy-cloud:* slash commands in one step:

/plugin marketplace add Comfy-Org/comfy-skills
/plugin install comfy-cloud@comfy-skills

Then run /mcp, select comfy-cloud → Authenticate, and finish the sign-in in your browser.

Prefer just the connection, without the plugin? Add the server directly (-s user makes it available in every project):

claude mcp add --transport http comfy-cloud https://cloud.comfy.org/mcp

and authenticate the same way, via /mcp.

Claude Desktop (cloud)

Claude Desktop adds it as a custom connector through its UI:

1. Sidebar → Customize → Connectors.
2. Click + in the Connectors header → Add custom connector.
3. Name it (e.g. Comfy Cloud MCP), set Remote MCP server URL to https://cloud.comfy.org/mcp, and click Add.
4. A browser window opens: choose your workspace and click Continue to authorize.

Cursor (cloud)

Cursor connects to remote MCP servers over HTTP but does not support MCP OAuth today, so use an API key. Add this to ~/.cursor/mcp.json (global) or .cursor/mcp.json (project), with COMFY_API_KEY set in your shell or system environment:

{
  "mcpServers": {
    "comfy-cloud": {
      "url": "https://cloud.comfy.org/mcp",
      "headers": {
        "X-API-Key": "${env:COMFY_API_KEY}"
      }
    }
  }
}

Other clients (cloud)

Any client with a remote HTTP MCP transport can connect to the same URL. Most use a JSON config with a url field (Windsurf uses serverUrl instead):

{
  "mcpServers": {
    "comfy-cloud": {
      "url": "https://cloud.comfy.org/mcp"
    }
  }
}

Sign in through the browser if the client supports MCP OAuth; otherwise add the X-API-Key header shown above. Restart the client and you should see the cloud tools (search_templates, submit_workflow, get_output, …) registered under the comfy-cloud server.

Codex and OpenClaw have first-class setup steps — including codex mcp add comfy-cloud --url https://cloud.comfy.org/mcp and openclaw mcp set / openclaw mcp login — in the Comfy Cloud MCP docs, which is also where the screenshot walkthroughs, the full cloud tool list, and the slash-command/prompt tables live.

Table of contents

• Quickstart
• Upgrading from comfy-local-mcp
• Configure your AI client
• Comfy Cloud MCP
• Prerequisites
• When to use this server
• Using with local LLMs (VRAM coordination)
• Partner-API nodes
• Spending credits on partner models
• Templates your install can't run
• Driving a remote ComfyUI
• Targeting a non-default ComfyUI address
• Which address variable do I want?
• Project anchoring
• Tools
• Troubleshooting
• Failure log (opt-in)
• Smoke test
• Contributing
• License
• Trademarks

Prerequisites

• Python ≥ 3.10.
• comfy-cli ≥ 1.14.0 on your PATH: pip install "comfy-cli>=1.14.0". This is the engine every tool wraps; the server refuses to run against an older comfy-cli with an upgrade message. 1.14.0 is the first release carrying everything this server needs. 1.13.0 brought the basics — the comfy logs verb, the envelope/1 contract, the comfy outdated verb behind server_info's freshness block, and the machine-readable login_url event auth_login waits for — but a large slice of the tool surface calls verbs that only exist from 1.14.0 on: comfy node deps (node_dependencies), system-stats / free, workflow notes (list_workflow_notes), logs --port, the background download group (--background plus download-status / downloads / download-cancel), models search's cross-folder walk, the templates gallery cache TTL, and comfy run's --allow-spend interlock. On 1.13.0 enough of the surface is inert that the server reads as broken rather than as out-of-date, which is why the floor moved rather than each tool degrading. Installing this server does not install comfy-cli — it is deliberately not a declared dependency of the comfy-mcp package, because the binary that matters is whichever one PATH / COMFY_BIN resolves to rather than one pinned into this server's environment, so the floor above is enforced at runtime against that binary (the rationale lives in pyproject.toml). Install the two together: pip install comfy-mcp "comfy-cli>=1.14.0".
• Every capability degrade is still in place, because the floor and a degrade guard different failures: the floor catches a wrong comfy-cli version, a degrade catches a correct version in a broken environment. The version guard fails open on a --version it can't parse (a source build, a fork), so such a build can still reach the tools from below the floor — and a dependency outside comfy-cli (a ComfyUI-Manager too old to know a flag comfy-cli forwarded to it) can fail on an otherwise-compliant install. In those cases you get a named capability gap — {"error": "…", "unsupported": true}, e.g. freshness: {"error": "freshness unavailable: …", "unsupported": true} — rather than a raw Click usage dump, and the rest of the tool keeps working.
• A ComfyUI workspace. If you don't have one, comfy-cli can create it: comfy install sets up a ComfyUI workspace it will point at. (An existing ComfyUI checkout works too — see comfy set-default <path>.)
• A running ComfyUI. ComfyUI must be started before you use the tools — launch it with comfy launch (or, from an agent, the launch_comfyui tool), and confirm it is up with server_info. Nothing here starts ComfyUI implicitly.

Optional environment variables (COMFY_BIN, COMFY_API_KEY, COMFYUI_URL, COMFY_MCP_REMOTE_SHARED_MODELS, COMFY_LOCAL_URL, COMFY_T2I_TEMPLATE; plus COMFY_USER_AGENT, which the server sets itself)

• COMFY_BIN override (optional). By default the server calls comfy from PATH. MCP clients launch the server with their own environment, which often does not include your shell's PATH — so if comfy lives in a virtualenv or a non-standard location, set COMFY_BIN to its absolute path (e.g. /path/to/venv/bin/comfy). Every example in Configure your AI client shows where it goes. Setting it is sufficient on its own — you do not also have to put that directory on the client's PATH. The server prepends the resolved binary's directory to the PATH it hands comfy-cli, because some comfy-cli commands (notably the background launch) re-invoke comfy by name and have to be able to find themselves.
• COMFY_API_KEY (optional — needed only for partner-API nodes). Workflows that use partner-API nodes (Seedream / Seedance / Nano Banana / Gemini / Veo / Kling / …) need a Comfy credential, and — exactly like COMFY_BIN — an MCP client launches the server with its own minimal environment, so a key from your shell won't reach it. Set COMFY_API_KEY in the client registration env block. See Partner-API nodes below for the full precedence chain; every example in Configure your AI client shows where it goes.
• COMFYUI_URL / COMFYUI_HOST / COMFYUI_PORT (optional — drive a ComfyUI on another machine). Read by this server. By default every tool targets 127.0.0.1:8188. Set COMFYUI_URL (e.g. http://gpu-box:8188) — or the COMFYUI_HOST (+ optional COMFYUI_PORT, default 8188) pair — to point the submit / job tools at a ComfyUI running elsewhere, e.g. a GPU box reachable over a private network (Tailscale). See Driving a remote ComfyUI for what is and isn't remoted. Unset ⇒ nothing changes.
• COMFY_MCP_REMOTE_SHARED_MODELS (optional — only meaningful alongside the variables above). download_model writes to this machine's models dir and has no remote mode, so with a remote configured it refuses rather than downloading onto the wrong disk. Set this to 1 when this machine's workspace models dir is the remote's — shared storage, e.g. an NFS / tailnet mount — to skip that guard and download as usual. Nothing else reads it, and it does nothing at all when no remote is configured.
• COMFY_LOCAL_URL (optional — a ComfyUI on this machine, on a non-default port). Read by comfy-cli, never by this server — it rides the environment passthrough, so setting it in the client env block re-points every tool. For a ComfyUI on this machine that isn't on 127.0.0.1:8188 (e.g. :8189 because Docker Desktop's ComfyUI holds :8188). See Targeting a non-default ComfyUI address, and Which address variable do I want? for the difference between the two.
• COMFY_USER_AGENT (set by the server — not yours to configure). Every comfy-cli call this server makes is labelled comfy-mcp, which is how comfy-cli tells work that came from this MCP apart from a human typing the same command — most usefully on the partner-API calls that spend credits. A value you set is overridden, on purpose: it would otherwise file this server's calls under someone else's name. The label is a caller identity, not content — nothing about your prompts, workflows, or outputs travels with it, and comfy-cli's own telemetry stays subject to comfy-cli's consent settings (comfy tracking disable, or the DO_NOT_TRACK / COMFY_NO_TELEMETRY environment variables, both of which this server passes straight through).
• COMFY_T2I_TEMPLATE / COMFY_T2I_PROMPT_SLOT / COMFY_T2I_CHECKPOINT_SLOT (optional — retarget generate_image). generate_image(prompt) runs the gallery's default template (ComfyUI's own basic SD1.5 text-to-image graph), filling its positive-prompt slot 6.text and, when you pass checkpoint, its ckpt_name slot. To point that on-ramp at a different local text-to-image graph, set all three together — the slot keys describe one specific template, so changing the template alone leaves the prompt address matching no slot. List a replacement's slots with comfy templates fetch <name> -o wf.json && comfy workflow slots wf.json. For a one-off run of some other template, prefer the run_template tool over these.

When to use this server

Local diffusion is only a good default on a machine that can actually carry it, so the server's client instructions tell your agent to read server_info's hardware block (os, arch, ram_bytes, and a gpu object with vendor / model / vram_bytes / unified_memory) before the first generation and route on it. The agent does not even have to make that call: at startup the server probes comfy env once and appends a Machine snapshot section — the same hardware block verbatim, plus the configured remote target if any — to the instructions the MCP handshake carries, so the routing figures are in the agent's context from the first message. The probe is best-effort: if it fails (no comfy on PATH yet, a timeout), the section is simply absent and the instructions still say to call server_info first; a healthy probe on an older comfy-cli that reports no hardware states the figure is unknown, which routes to step 3 below (ask). The snapshot never carries live state — whether a server is running stays server_info's job. The thresholds:

Machine	Guidance
Discrete GPU, ≥ 24 GB VRAM	Local generation is a good default.
Discrete GPU, 8 GB to under 24 GB VRAM	Images are fine (prefer current, smaller models); video will be slow or infeasible.
< 8 GB VRAM, or the user confirming there is no GPU	Don't run local diffusion. Use partner nodes (plain web calls, fine on any machine) or the Comfy Cloud MCP if your client has it connected.
Apple Silicon, ≥ 32 GB unified memory	Images are OK. Video on the Apple GPU is not recommended — time estimates are unreliable and thermals suffer.
Apple Silicon, under 32 GB unified memory	Same as the no-GPU row above — go partner/cloud rather than local.

The discrete-GPU rows are written for NVIDIA but apply to an AMD or Intel card on a ROCm/XPU build too — the VRAM number is what matters. The no-local-video rule is an Apple GPU rule rather than a Mac rule: an Intel Mac with a discrete card follows the discrete-GPU rows.

The instructions walk these as an ordered procedure, because several of the checks only make sense in sequence:

1. Is the work even local? hardware describes the machine this server runs on, and that is where most tools execute. A comfy_target block (Driving a remote ComfyUI) diverts every tool that submits a job — run_workflow, generate_image, run_template — along with the queue/jobs tools, while discovery, templates, downloads, outputs and the lifecycle tools stay here; so against a genuine remote the thresholds below describe the wrong machine. It counts as another machine only when its host is neither loopback (anything in 127.0.0.0/8, localhost, IPv6 ::1) nor this host's own address, and a malformed config produces an error-shaped {error, note} block that resolves no remote at all. Nothing the server returns carries the local hostname or interface addresses, so a host the agent can't place is a question for you rather than a guess — a hostname or LAN IP can be this same machine, and a loopback host can be a tunnel to a remote GPU. COMFY_LOCAL_URL is a second signal worth checking: it repoints comfy-cli without producing a comfy_target block.
2. Get a memory figure. The sizes are bytes (ram_bytes, gpu.vram_bytes) and the divisor gives GiB, while drivers report under the advertised size — a consumer 24 GB card reads 23.99, an ECC/reserving datacenter card (A10, L4) about 22.3 — so a small shortfall, within ~10% of a nominal size, reads as that nominal capacity. A gap wider than that is not driver overhead and is taken at face value instead: on a MIG/vGPU partition the model string names the whole card while vram_bytes is the slice you actually get, and rounding a 6 GB A100 slice up into the ≥ 24 GB band would OOM the run. On Apple Silicon gpu.vram_bytes is null (with gpu.unified_memory true) and the figure is ram_bytes — an Apple-only substitution.
3. If the figure is missing, ask. A null or zero vram_bytes on any non-Apple GPU (a discrete card comfy-cli can't size, but also a non-Apple unified part like a Jetson/Grace board or a Strix Halo APU), a missing gpu object, or a missing/zero ram_bytes on the Apple path all mean unknown, not "no GPU" — the agent asks rather than stranding a machine that has one. The "no GPU" verdict is reserved for a confirmed absence, and the only thing that confirms one is your own answer: no hardware payload encodes it, because a null or missing gpu is unknown by this same step. Nothing in this repo probes hardware, and the instructions tell the agent not to shell out either: a probe runs on a path this server can neither bound nor audit.
4. Route on the figure, then redirect rather than dead-end when the answer is "not on this machine". A figure that came from your answer rather than the payload routes on whichever row fits the machine — the unified-memory row on an Apple Silicon Mac, the VRAM rows otherwise, which is what covers the non-Apple unified-memory boards that have no row of their own.

"No local video on a Mac" is about the Apple GPU, not about video as such: API-tagged video templates (search_templates(tag="API", type="video") — both filters, since neither alone isolates partner-run video; each row's api boolean then confirms which side of the line it fell on) and emit_partner_workflow run the model on partner infrastructure, so they work on any machine. See Partner-API nodes.

The hardware block comes straight through from comfy env, and a comfy-cli that predates it simply omits the key. There is no HTTP client and no cloud code here — the cloud/partner steer is guidance text only.

Which model to use is deliberately not encoded here. The instructions tell the agent to pick via search_templates / search_models rather than assume a classic default (e.g. SDXL), because the gallery tracks current models and a hardcoded name would rot. Current-model guidance lives in Comfy-Org/comfy-skills, which is its canonical home.

Using with local LLMs (VRAM coordination)

Running a local LLM (Ollama, LM Studio, llama.cpp) and ComfyUI on the same GPU means the two compete for the same VRAM, and the LLM is usually the one holding it when the image job needs it. This server gives the agent both halves of the read/free loop, but the coordination is the client's — see why below.

The recipe, in order:

1. Read the headroom. system_stats() returns per-device vram_free / vram_total straight from the live ComfyUI. Compare vram_free against what the workflow's checkpoint needs.
2. If it is tight, the client unloads its own LLM using its runtime's own mechanism — this server has no way to do it (step 5 below):
   • Ollama — send keep_alive: 0 on the next /api/generate (or /api/chat) call, which unloads the model as soon as that call returns, or run ollama stop <model>.
   • LM Studio — let the model's TTL / JIT auto-evict expire, or unload explicitly with lms unload <model> (lms unload --all for everything).
   • llama.cpp (llama-server)

…