In the previous articles of the Beyond the ComfyUI Canvas series, I connected ComfyUI to notebooks, WebSockets, n8n, and Flowise. I even created my own MCP Server. Each integration worked, but it still required me to write or maintain the glue: HTTP payloads, polling loops, node IDs, and workflow-specific code.
Today, I am taking a more direct route. I will connect a local ComfyUI installation to Codex through the official open-source Comfy MCP server.
The goal is simple: let an AI agent inspect the local ComfyUI instance, discover installed models, validate an existing workflow, run it, wait for completion, and bring the generated image back into the conversation.
No custom Python bridge. No hand-written /prompt request. The agent uses a standard MCP tool interface; Comfy MCP translates those tool calls into comfy-cli commands targeting my local ComfyUI server.
1. Setting the Scene: The Stack
The local stack I used has three layers:
- Codex is the agent and MCP client. It receives natural-language requests and decides which tools to call.
-
Comfy MCP is the open-source MCP server from Comfy. It runs as a local stdio process and wraps
comfy-cli. -
ComfyUI is the generation engine, running locally at
http://127.0.0.1:8188on a GPU-equipped machine.
This is not Comfy Cloud MCP. The complete flow stays on the local machine: the workflow, models, queue, and generated images all remain in the local ComfyUI workspace. The only exception is a workflow that deliberately uses paid partner API nodes.
2. Install the Local Components
Let Codex do the setup
Steps 2 and 3 can be delegated to Codex itself. Instead of manually installing packages and editing the MCP configuration, give Codex this prompt:
Help me set up the local Comfy MCP connection.
Follow the setup guide at https://docs.comfy.org/agent-tools/mcp.md#local-comfy-mcp-connection
Codex can inspect the machine, install the required packages, create or locate the ComfyUI workspace, configure the MCP server, and then verify the connection. It should still show you any required permissions before making changes outside its workspace.
The Comfy MCP server is built on top of comfy-cli, so both packages are required:
py -m pip install comfy-mcp "comfy-cli>=1.14.0"
If ComfyUI is not installed yet, create a workspace with:
comfy install
For an existing workspace, make it the default instead:
comfy set-default C:\path\to\ComfyUI
Then launch the local server:
comfy launch
In my case, ComfyUI was installed in C:\Users\rapha\Documents\comfy\ComfyUI and became available at http://127.0.0.1:8188.
The Windows PATH trap
On Windows, packages installed with Python can place comfy.exe and comfy-mcp.exe in a Scripts directory that is not on the PATH inherited by desktop applications.
That can be confusing: the MCP server starts and completes its handshake, but every useful tool fails with:
comfy not found on PATH
The robust fix is to configure COMFY_BIN with the absolute path to comfy.exe. It makes the MCP server independent from the client application's PATH.
3. Connect Comfy MCP to Codex
Codex stores local MCP servers in its configuration. Add the following to ~/.codex/config.toml, adapting the paths to your Python installation:
[mcp_servers.comfy-mcp]
command = 'C:\Users\<you>\AppData\Roaming\Python\Python313\Scripts\comfy-mcp.exe'
[mcp_servers.comfy-mcp.env]
COMFY_BIN = 'C:\Users\<you>\AppData\Roaming\Python\Python313\Scripts\comfy.exe'
Restart or reload Codex after changing the configuration. The server is a stdio MCP server: Codex launches comfy-mcp as a subprocess when it needs the tools.
COMFY_API_KEYis not required for local Flux, SDXL, or other locally installed models. Add it only when you intentionally use Comfy partner API nodes that spend credits.
4. First Contact: Verify the Engine and Inspect Models
The first useful test is not image generation. It is asking Codex to inspect the live server:
Confirm that my local ComfyUI is running and list the installed models.
Under the hood, Codex calls Comfy MCP's server_info and search_models tools. In my test, the server reported a healthy local ComfyUI instance at 127.0.0.1:8188, and the model search found the locally installed Flux 2 Klein model, VAEs, text encoders, LoRAs, and checkpoint files.
This is an important difference from a static prompt template. The agent can inspect what this ComfyUI instance actually has before it attempts a workflow. That makes it much easier to diagnose a missing model or a custom-node mismatch.
Other operational actions are available through the same connection:
server_info # health, server address and capabilities
search_models # models visible to this ComfyUI instance
search_templates # templates from the Comfy registry
launch_comfyui # start the local server
stop_comfyui # stop the local server
get_logs # inspect server logs when a run fails
5. Workflows: Templates vs. Local Exports
There are two workflow paths worth keeping separate.
Registry templates
For a Comfy template, the agent can search the registry, inspect a template, fetch it into a runnable JSON file, validate it against the local installation, and run it.
Your own workflows
For a workflow created in the ComfyUI canvas, export it as JSON and give Codex the file path. Comfy MCP's run_workflow accepts both API-format workflow JSON and a UI-exported workflow file.
This is the path I used for image_flux2_text_to_image.json, a Flux 2 Klein text-to-image workflow. The workflow contained a dedicated prompt input wired to the positive conditioning node, so changing the prompt did not require rebuilding the graph.
The practical rule is simple: templates are discovered from the registry; personal workflows are supplied as exported JSON files.
6. The Use Case: A Cyberpunk Image from a Conversation
With the connection tested, I asked Codex to create an evocative cyberpunk prompt and generate an image with the existing Flux workflow.
The prompt injected into the workflow was:
A lone courier in a rain-soaked neon megacity at midnight, riding a sleek black
motorcycle through a narrow alley beneath towering holographic billboards;
crimson and electric cyan reflections ripple across wet pavement, steam drifting
from street vents, distant elevated trains, cinematic low-angle composition,
moody noir atmosphere, intricate futuristic street details, expressive visual
storytelling, photorealistic, high contrast, luminous volumetric rain
The agent followed a safe execution sequence:
1. validate_workflow(workflow_path)
2. run_workflow(workflow_path, wait=false)
3. job(action="wait", prompt_id=...)
4. fetch_outputs(prompt_id, out_dir="./outputs")
5. Display the downloaded image in Codex
The validation result was clean: no errors, no warnings, and no credit-spending nodes. ComfyUI then queued the job, rendered it locally, and returned an output URL. fetch_outputs copied the completed PNG into the Codex workspace, where it could be displayed directly in the conversation.
The output is more than a pretty picture. It proves the full control loop:
7. What MCP Removes — and What It Does Not
MCP removes a large amount of integration boilerplate. I no longer have to manually craft the ComfyUI /prompt payload, invent a polling loop, or reconstruct /view URLs in every application. The tools provide a consistent interface for lifecycle management, discovery, validation, execution, and outputs.
But MCP does not remove the value of a well-designed workflow. The JSON graph still defines the actual generation process: which model is loaded, where the prompt is injected, which sampler runs, and which node saves the output. The cleanest pattern is to keep reusable workflows in source control and let the agent execute validated copies of those files.
It is also worth keeping two guardrails in mind:
- Validate before running. A workflow can refer to a model or custom node that is absent from the local instance.
- Confirm paid execution deliberately. Local workflows are usually free apart from hardware and electricity, but partner API nodes can consume Comfy credits.
Conclusion
Connecting Codex to local ComfyUI through the open-source Comfy MCP server changes the relationship between the agent and the generation engine. ComfyUI is no longer only a canvas I open by hand; it becomes a discoverable, controllable local capability.
In this experiment, I installed the MCP bridge, configured Codex with an explicit COMFY_BIN, launched and inspected the local server, enumerated the installed models, validated an existing Flux workflow, generated an image, waited for completion, and retrieved the output—all from one conversation.
The next step is to treat a library of exported ComfyUI workflows as an agent-accessible creative toolbox: text-to-image, image-to-image, upscaling, video, audio, and more. The graph remains the source of truth, while MCP gives the agent a reliable way to use it.
Top comments (0)