Skip to main content
Glama
aschet

comfygenmcp

by aschet
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

uncomfymcp

A Model Context Protocol (MCP) server that connects an AI assistant to a running ComfyUI instance. It fetches a workflow saved in ComfyUI, writes the prompt and seed into it, runs it, and returns the image inline in the chat — so it only works with text-to-image workflows that have a single prompt node and seed to inject into.

This is a third-party MCP server for ComfyUI. The official one, comfy-mcp, is available at https://github.com/Comfy-Org/comfy-mcp

Install

Requires Python 3.10+ and a running ComfyUI.

Linux and macOS:

git clone https://github.com/aschet/uncomfymcp.git
cd uncomfymcp
python3 -m venv .venv
.venv/bin/pip install -e .

Windows:

git clone https://github.com/aschet/uncomfymcp.git
cd uncomfymcp
python -m venv .venv
.venv\Scripts\pip install -e .

That gives you the command .venv/bin/uncomfymcp (.venv\Scripts\uncomfymcp.exe on Windows), which a client launches for you — nothing to start by hand beyond ComfyUI itself.

Related MCP server: comfyui-mcp

Connecting a Client

Any MCP client works. By default the server speaks stdio, meaning the client launches .venv/bin/uncomfymcp itself and talks to it over the process pipes. With --transport http it instead listens on http://127.0.0.1:8000/mcp for clients that connect over the network — with no authentication, so don't expose it without one in front.

Add this mcpServers entry to the client's config. Flags go in an "args" array, e.g. "args": ["--comfy-url", "http://host:8188", "--timeout", "600"] — add the first if ComfyUI isn't on localhost, and raise the timeout if your workflows are slow or an agent chains several generations.

{
  "mcpServers": {
    "uncomfy": {
      "command": "/path/to/uncomfymcp/.venv/bin/uncomfymcp"
    }
  }
}

On Windows, command is the .venv\Scripts\uncomfymcp.exe path instead.

  • Claude Desktop: add it to claude_desktop_config.json.

  • AnythingLLM: add it to anythingllm_mcp_servers.json (~/.config/anythingllm-desktop/storage/plugins/ on Linux), then start it from Settings → Agent Skills → MCP Servers and invoke with @agent. It renders no image at all, so add --no-inline-image to "args" — otherwise every generation wastes tens of thousands of tokens on base64 the agent can't even display.

Use

Claude Desktop

you:    which image workflows do I have?
claude: [list_workflows]
        Ready to generate with:
          Krea2
          Z-Image Turbo

        Present but not usable:
          Ideogram 4 -- needs models that are not installed:
          flux2-vae.safetensors, gemma4_e4b_it_fp8_scaled.safetensors,
          ideogram4_fp8_scaled.safetensors

you:    generate a red fox in deep snow using Krea2
claude: [image]  Krea2 · seed 12345 ·
        http://127.0.0.1:8188/view?filename=Krea2_turbo_00007_.png

The image shows inside the collapsed tool card — expand it, or use the URL.

AnythingLLM

Tool calls need the @agent prefix, and with --no-inline-image set (see above) there is no [image] block, only the line with the seed and URL:

you:    @agent generate a red fox in deep snow using Krea2
agent:  Krea2 · seed 12345 ·
        http://127.0.0.1:8188/view?filename=Krea2_turbo_00007_.png

Two tools are exposed:

Tool

Description

generate_image(prompt, workflow, seed?)

Generate and return the image. Seeds are random unless you pass one, and every result reports the seed it used. Pass --no-inline-image on the command line for a client that can't render one — it then returns only the seed and URL.

list_workflows()

The workflows saved in ComfyUI, split into those ready to run and those that cannot.

Limitations

  • Only the prompt and seed change — no width, height, steps or sampler; those come from the workflow. A sampler set to "fixed" in ComfyUI is not honoured.

  • Node detection can pick the wrong node when a workflow has several prompt boxes; set a node's Title to MCP:prompt to override.

  • Images are sent as WebP, downscaled and compressed to fit a 1 MB limit, with transparency preserved. The full-resolution original stays in ComfyUI's output folder.

Configuration

All settings are command-line flags.

Flag

Default

Description

--comfy-url

http://127.0.0.1:8188

Address of the ComfyUI server to generate on

--transport

stdio

stdio, or http to listen on a port

--listen

127.0.0.1:8000

Address this server binds to, with --transport http

--timeout

300

Seconds before giving up on a generation

Available Tools

2 tools
generate_imageA

Generate an image on ComfyUI and return it inline.

Returns " · seed · " plus -- unless this server was started with --no-inline-image -- the image itself.

Clients usually collapse tool results, so the image is easy to miss. Pass the URL on in your reply: it survives the collapse, and is how the user sees the picture when no image is returned. Write it bare so the client turns it into a link -- code formatting or backticks make it unclickable.

Use exactly the workflow name the user asked for. Similar names are different workflows -- "Krea2" and "Krea2+Upscale" are not interchangeable.

Fails if the workflow needs an input image or has no prompt node to patch.

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNoReuse a seed from an earlier result to reproduce it. Omit for a new one.
promptYesWhat to draw, in plain language.
workflowYesName of a workflow saved in ComfyUI, exactly as list_workflows returns it. If you do not have a name yet, call list_workflows and use the first ready one rather than asking the user to choose.

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so thoroughly. It discloses the exact return format, the inline image behavior under --no-inline-image, client collapse behavior, URL formatting requirements, and failure modes. This is far beyond minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the primary purpose, then systematically covers return format, client behavior, URL handling, workflow matching, and failure conditions. Although it is moderately long, every sentence provides actionable information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description fully explains the return value and its nuances. It also covers server configuration, client UI behavior, and failure conditions. No critical operational detail is missing for an agent to invoke the tool successfully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaningful context for the workflow parameter: exact name as returned by list_workflows, directive to call list_workflows if unknown, and warning that similar names are not interchangeable. This extra guidance justifies a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates an image on ComfyUI and returns it inline. The verb 'generate' and resource 'image' are specific, and it is easily distinguished from the only sibling list_workflows, which is a prerequisite rather than an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to call list_workflows first (when no workflow name is known) and warns about exact workflow-name matching. It also states failure conditions (workflow needs input image or lacks a prompt node), giving clear when-not-to-use information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_workflowsA

List the workflows saved in ComfyUI, ready ones first.

Call this instead of asking the user which workflows they have -- they expect you to look.

The reply separates workflows that can generate from those that cannot, because the models they reference are not installed or no prompt node was found. Only use the ready ones; naming another will fail.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations or output schema, the description carries the full burden and delivers: it states the readiness ordering, the separation of runnable vs non-runnable workflows, the likely causes, and the consequence of using an unready one.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with no filler; the core purpose comes first, followed by usage context and a critical behavioral warning. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter listing tool with no output schema, the description is complete: purpose, ordering, meaning of readiness, and failure mode are all covered. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is nothing for the description to document. Baseline of 4 applies because there is no parameter information needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses a specific verb 'List' with a clear resource ('workflows saved in ComfyUI') and adds ordering scope ('ready ones first'). It makes the tool's role obvious relative to the sibling generate_image, which performs generation rather than discovery.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells the agent to call this instead of asking the user, with the user expectation rationale. It also warns to only use ready workflows and that naming another will fail, providing clear downstream guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedgenerate_image
    • First observedlist_workflows
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.7/5.0

Scored across 2 tools

Disambiguation5/5

list_workflows and generate_image are completely distinct: one discovers available workflows, the other executes generation. There is no possibility of confusing their roles.

Naming Consistency5/5

Both tool names follow the same verb_noun pattern (list_workflows, generate_image), making the interface predictable and consistent.

Tool Count3/5

At only 2 tools, the server feels thin, but the narrow scope of listing and generating ComfyUI workflows makes this minimal surface reasonable. Still, it is borderline per the calibration guideline.

Completeness4/5

The core workflow is complete: list ready workflows and generate images from them. Minor gaps exist, such as no workflow detail endpoint or explicit handling of input-image workflows, but these are edge cases rather than dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • comfyui-mcp

    KerbalTheGathering
    F
    license
    Not graded
    quality
    C
    maintenance
    MCP server exposing a local (or LAN) ComfyUI instance's HTTP API as tools, so an LLM client can queue generations, inspect the queue/history, upload reference images, browse installed models/nodes, and pull back generated images.
    -

  • comfy-mcp

    cuzelac
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server that enables AI agents to control a local ComfyUI instance for image generation, allowing workflow understanding, parameter modification, execution, and model discovery.
    23 npm
    3
    Apache 2.0

  • ComfyUI MCP Server

    a-misen
    F
    license
    A
    quality
    D
    maintenance
    An MCP server for generating images and checking generation status through ComfyUI's API. It allows interaction with local ComfyUI instances by providing workflow-based image generation and status checking tools.
    3
    -