This server acts as an MCP gateway for ComfyUI, enabling image generation, editing, and processing via AI workflows.
Text-to-Image Generation: Generate images from text prompts using built-in workflows:
Sensenova (supports Chinese prompts, aspect ratio, steps, CFG, seed, batch size)
Z-Image Turbo (fast Lumina2-based generation with configurable resolution, sampler, scheduler)
Qwen-Image-2512 + LoRA (high-quality images with negative prompt and LoRA strength controls)
Background Removal: Remove backgrounds from images using the BiRefNet model.
Image Upscaling: Upscale images to 2K resolution using RealESRGAN + Z-Image Turbo.
Reboot ComfyUI: Remotely restart the ComfyUI service and wait for it to recover.
Batch Processing: Repeat tasks a fixed number of times (submit_batch) or over a time duration (batch_by_time).
Local Output Download: Specify an output_dir to download generated images locally, with Markdown image links returned.
Custom Workflow Support: Automatically register any .json workflow files from local directories as MCP tools, and optionally sync workflows directly from a ComfyUI instance on startup.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-comfyui generate an image of a serene mountain landscape"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
通过 MCP (Model Context Protocol) 协议调用 ComfyUI，加载并执行 workflow：文生图、图编辑、放大、去背景等。适用于 opencode、Claude Code、Cursor 等 MCP 客户端。
uvx --from git+https://github.com/bookandmusic/comfyui-mcp.git comfyui-mcp \
--comfyui.host 127.0.0.1:8188首次运行自动下载依赖并创建隔离虚拟环境。5 个内置 workflow 开箱即用，无需额外配置。
Related MCP server: comfyui-mcp
bundled_ 前缀）工具名 | 说明 |
| Sensenova 文生图 |
| Z-Image Turbo 文生图 |
| Qwen-Image-2512 + LoRA 文生图 |
| BiRefNet 去背景 |
| Z-Image Turbo 2K 放大 |
工具名 | 说明 |
| 重启 ComfyUI 服务，等待恢复后返回成功消息 |
放入 --comfyui.workflow_directory 的 .json 文件会自动注册为工具，工具名为文件名中的 . 替换为 _，例如 my_workflow.json → my_workflow。
参数 | 类型 | 说明 |
| string | 图像描述（非必填，由具体 workflow 决定） |
| int | 随机种子，留空自动生成。多批时自动递增 |
| bool | 按时间轮询（分钟），与 |
| int | 重复执行次数，或 |
| string | 可选，本地目录。提供时将结果图片下载到此目录并返回 Markdown 图片链接 |
comfyui-mcp 的所有配置通过命令行参数传入，不支持配置文件。启动参数如下：
参数 | 默认值 | 说明 |
|
| ComfyUI 服务的 host:port |
|
| 本地工作流目录（sync 时也作为下载目标） |
|
| 额外工作流目录列表 |
|
| 启动时从 ComfyUI 同步所有 |
|
| HTTP 请求超时（秒） |
|
| 失败重试次数 |
|
| 队列轮询间隔（秒） |
|
| 任务最长等待时间（秒， |
|
|
|
1. 内置 workflow
随 wheel 打包，始终加载。工具名带 bundled_ 前缀，不与用户 workflow 冲突。
2. 本地目录
--comfyui.workflow_directory 指定的目录（默认 ~/.config/comfyui-mcp/workflows/）。放入 .json 文件，重启后自动注册。目录不存在时自动创建。
cp my-workflow.json ~/.config/comfyui-mcp/workflows/需要多个目录时：
--comfyui.additional_workflow_directories '["/path/to/dir1", "/path/to/dir2"]'3. 从 ComfyUI 同步（可选）
--comfyui.sync_from_comfyui true 启动后，MCP 调用 ComfyUI 的 /api/v2/userdata 列出所有 .json 文件并下载到本地 workflow_directory。适用于集中式 workflow 库 + 多 MCP 实例、跨机部署等场景。
uvx --from git+https://github.com/bookandmusic/comfyui-mcp.git comfyui-mcp \
--comfyui.host 127.0.0.1:8188 \
--comfyui.sync_from_comfyui true注意：同步范围包括 userdata 下所有
.json（含非 workflow 的配置如styles.json），缺少nodes字段的文件会报加载错误但不中断启动。
{
"mcp": {
"comfyui": {
"type": "local",
"command": [
"uvx",
"--from", "git+https://github.com/bookandmusic/comfyui-mcp.git",
"comfyui-mcp",
"--comfyui.host", "127.0.0.1:8188"
],
"enabled": true,
"timeout": 600000
}
}
}添加到 ~/.claude/settings.json：
{
"mcpServers": {
"comfyui": {
"command": "uvx",
"args": [
"--from", "git+https://github.com/bookandmusic/comfyui-mcp.git",
"comfyui-mcp",
"--comfyui.host", "127.0.0.1:8188"
]
}
}
}也可放在项目级 .claude/settings.local.json 中。
git clone https://github.com/bookandmusic/comfyui-mcp.git
cd comfyui-mcp
uv sync
uv run python -m comfyui_mcp.server --comfyui.host 127.0.0.1:8188或安装为本地命令：
uv tool install .
comfyui-mcp --comfyui.host 127.0.0.1:8188MIT — 详见 LICENSE。
Comfy image generation workflow image_z_image_turbo.json
| Name | Required | Description | Default |
|---|---|---|---|
| cfg | No | ||
| seed | No | ||
| text | No | Latina female with thick wavy hair, harbor boats and pastel houses behind. Breezy seaside light, warm tones, cinematic close-up. | |
| type | No | lumina2 | |
| shift | No | ||
| steps | No | ||
| width | No | ||
| height | No | ||
| denoise | No | ||
| vae_name | No | ae.safetensors | |
| clip_name | No | qwen_3_4b.safetensors | |
| scheduler | No | simple | |
| unet_name | No | z_image_turbo_bf16.safetensors | |
| batch_size | No | ||
| output_dir | No | ||
| sampler_name | No | res_multistep | |
| submit_batch | No | ||
| weight_dtype | No | default | |
| batch_by_time | No | ||
| filename_prefix | No | z-image-turbo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'image generation workflow', offering no details on side effects, required permissions, resource usage, or what modifications occur. This is insufficient for a tool with 20 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise, but it sacrifices all informative content. It is front-loaded but provides no value beyond the tool name, failing to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (20), no output schema, and no annotations, the description is critically incomplete. It does not explain how the workflow processes inputs, what outputs to expect, or any operational constraints, leaving the agent with no usable context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the input schema provides no descriptions for any of the 20 parameters. The description adds no parameter information, so the agent must infer purpose solely from parameter names like 'cfg', 'seed', or 'vae_name', which is highly ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Comfy image generation workflow image_z_image_turbo.json', which indicates the tool generates images using a specific workflow. However, it does not differentiate this workflow from sibling tools like bundled_qwen_image_2512_with_lora_json or bundled_sensenova_json, leaving ambiguity about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about scenarios, prerequisites, or exclusions, leaving the agent without direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comfy image generation workflow qwen_image_2512_with_lora.json
| Name | Required | Description | Default |
|---|---|---|---|
| cfg | No | ||
| seed | No | ||
| type | No | qwen_image | |
| shift | No | ||
| steps | No | ||
| width | No | ||
| height | No | ||
| denoise | No | ||
| vae_name | No | qwen_image_vae.safetensors | |
| clip_name | No | qwen_2.5_vl_7b_fp8_scaled.safetensors | |
| lora_name | No | Qwen-Image-2512-Lightning-4steps-V1.0-fp32.safetensors | |
| scheduler | No | simple | |
| unet_name | No | qwen_image_2512_fp8_e4m3fn.safetensors | |
| batch_size | No | ||
| output_dir | No | ||
| CLIP___text | No | realistic, photorealistic, human proportions, blurry, deformed, ugly, low quality, watermark, text | |
| sampler_name | No | euler | |
| submit_batch | No | ||
| weight_dtype | No | default | |
| batch_by_time | No | ||
| strength_clip | No | ||
| strength_model | No | ||
| filename_prefix | No | qwen-2512 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks any behavioral details such as side effects, authentication needs, or operational constraints. The description is essentially empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the sentence is uninformative and does not justify its existence. It is under-specified, not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 23 parameters, no output schema, and no annotations, the description is critically incomplete. It fails to explain inputs, outputs, or purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (description adds no parameter info) and there are 23 parameters with defaults but no explanations. The description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Comfy image generation workflow' identifies the domain but does not specify what the tool does beyond restating the file name. It fails to distinguish from sibling tools like 'bundled_image_z_image_turbo_json'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Context for usage is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comfy image generation workflow sensenova.json
| Name | Required | Description | Default |
|---|---|---|---|
| cfg | No | ||
| seed | No | ||
| steps | No | ||
| prompt | No | 这是一张主题为"夏日清凉指南"的信息图，采用16:9宽高比，4K分辨率，面向大众读者，旨在提供实用的夏季避暑建议。整体风格为现代扁平化设计，配色以清凉的浅蓝色、薄荷绿和白色为主，背景采用带有轻微纸张纹理的浅灰色，营造清爽舒适的视觉氛围。构图采用Bento网格布局，分为五个主要模块，每个模块用圆角矩形框区分，模块间通过细线分隔，留白充足。 ## 整体布局 - 顶部标题区：大字号主标题"夏日清凉指南"，副标题"避暑全攻略"，居中对齐，字体采用无衬线粗体，颜色为深蓝色。 - 主体区：采用2x3网格布局，包含五个内容模块： 1. 左上："避暑胜地推荐" - 用地图图标和列表展示推荐地点 2. 右上："防暑小贴士" - 用盾牌图标和要点列表展示防护措施 3. 左中："清凉饮品推荐" - 用饮料图标和卡片展示饮品类型 4. 右中："避暑装备清单" - 用背包图标和清单展示必备物品 5. 底部："中暑急救指南" - 用急救十字图标和流程图展示急救步骤 - 每个模块包含：图标（扁平化风格，蓝色系）、标题（加粗）、内容（列表或简短说明）、装饰性元素（如小太阳、水滴、树叶等夏日元素）。 ## 背景与风格 - 背景：浅灰色纸张纹理，带有细微的网格线 - 风格：现代扁平化设计，简洁明快 - 配色：主色调为浅蓝色、薄荷绿、白色，强调色为橙色用于高亮重要信息 - 字体：中文采用思源黑体，英文采用Roboto ## 内容分区 ### 分区1: 避暑胜地推荐 - 视觉元素：山脉图标、温度计图标（显示低温）、列表项图标 - 文字标签："避暑胜地推荐"、"高山地区"、"海滨城市"、"森林景区" - 数据呈现：用地图轮廓和地点标记展示推荐区域 ### 分区2: 防暑小贴士 - 视觉元素：盾牌图标、太阳图标（带斜杠）、水滴图标 - 文字标签："防暑小贴士"、"避免正午外出"、"多补充水分"、"穿着透气衣物" - 数据呈现：用图标+短句的形式展示 ### 分区3: 清凉饮品推荐 - 视觉元素：饮料杯图标、西瓜图标、柠檬图标 - 文字标签："清凉饮品推荐"、"绿豆汤"、"柠檬水"、"凉茶" - 数据呈现：用饮品卡片展示，每张卡片包含饮品名称和简短描述 ### 分区4: 避暑装备清单 - 视觉元素：背包图标、遮阳伞图标、防晒霜瓶子图标 - 文字标签："避暑装备清单"、"遮阳帽"、"防晒霜"、"便携风扇" - 数据呈现：用清单形式展示，每项前带复选框图标 ### 分区5: 中暑急救指南 - 视觉元素：急救十字图标、流程图箭头、人物图标 - 文字标签："中暑急救指南"、"移至阴凉处"、"补充水分"、"必要时就医" - 数据呈现：用流程图形式展示急救步骤，箭头连接各步骤 ## 视觉细节 - 字体：主标题32pt粗体，副标题24pt，模块标题18pt粗体，正文14pt - 图标：统一使用扁平化线性图标，线条粗细一致，颜色为深蓝色 - 连接线：模块间用浅灰色细线分隔，流程图用蓝色箭头连接 - 留白：每个模块内部留白充足，模块间距为20px - 装饰元素：角落点缀小太阳、水滴、树叶等夏日元素，增加氛围感 | |
| img_cfg | No | ||
| batch_size | No | ||
| output_dir | No | ||
| submit_batch | No | ||
| batch_by_time | No | ||
| target_pixels | No | 16:9 | |
| filename_prefix | No | ComfyUI |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose any behavioral traits such as side effects, authentication requirements, rate limits, or what happens to input/output. The word 'workflow' hints at complexity but nothing concrete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, under-specified phrase. It is too short to be helpful; 'conciseness' implies efficiency without loss of meaning, but this sacrifices essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description is wholly inadequate. It provides no information on how the workflow behaves, what it outputs, or how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 11 parameters, and the description adds no explanation for parameters like 'submit_batch', 'batch_by_time', 'target_pixels', or 'filename_prefix'. The description does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Comfy image generation workflow sensenova.json' is a noun phrase without a verb. It vaguely suggests image generation but does not state an action (e.g., 'Generates images using...') or distinguish from sibling tools like bundled_image_z_image_turbo_json or bundled_qwen_image_2512_with_lora_json.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Sibling tools perform similar image tasks, but the description gives no decision criteria or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comfy image generation workflow utility_birefnet_remove_background.json
| Name | Required | Description | Default |
|---|---|---|---|
| p_ | No | robot-toy-figure_00001_.png [output] | |
| output_dir | No | ||
| submit_batch | No | ||
| batch_by_time | No | ||
| bg_removal_name | No | birefnet.safetensors | |
| p___filename_prefix | No | mask |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only repeats the tool name. It fails to state that this tool removes backgrounds (implied by name), any safety considerations, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is only one sentence, it is under-specification rather than conciseness. The sentence adds no useful information beyond the tool name, and every word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with no descriptions, no annotations, no output schema, and no usage context, the description is completely inadequate. It fails to meet the minimum needed for an agent to understand or use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 6 parameters with 0% schema description coverage and no descriptions in the schema. The tool description adds no meaning to any parameter (e.g., p_, output_dir, submit_batch, etc.), leaving their purpose entirely unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology, merely restating the tool name 'bundled_utility_birefnet_remove_background_json' as 'Comfy image generation workflow utility_birefnet_remove_background.json'. It does not explain what the tool does in terms of specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus any of its siblings (e.g., bundled_image_z_image_turbo_json, bundled_qwen_image_2512_with_lora_json, etc.). The description gives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comfy image generation workflow utility_z_image_turbo_2k_upscaler.json
| Name | Required | Description | Default |
|---|---|---|---|
| p_ | No | qwen-2512_00018_.png [output] | |
| cfg | No | ||
| seed | No | ||
| type | No | lumina2 | |
| shift | No | ||
| steps | No | ||
| denoise | No | ||
| scale_by | No | ||
| vae_name | No | ae.safetensors | |
| clip_name | No | qwen_3_4b.safetensors | |
| scheduler | No | beta | |
| unet_name | No | z_image_turbo_bf16.safetensors | |
| megapixels | No | ||
| model_name | No | RealESRGAN_x4plus.safetensors | |
| output_dir | No | ||
| sampler_name | No | dpmpp_2m_sde | |
| submit_batch | No | ||
| weight_dtype | No | default | |
| batch_by_time | No | ||
| filename_prefix | No | z-image-upscaled | |
| p___upscale_method | No | lanczos | |
| CLIP_Text_Encode_Negative_Prompt___text | No | ||
| CLIP_Text_Encode_Positive_Prompt___text | No | masterpiece, 8k |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no behavioral context whatsoever—no mention of side effects, permissions, or operational behavior. The agent has zero insight beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the expense of information. It is not concise in a useful way; it is merely underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 23 parameters, no output schema, and no annotations, the description is grossly insufficient to enable correct tool selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 23 parameters. Parameter names like 'p_', 'cfg', 'seed' are opaque without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description simply repeats the tool name ('Comfy image generation workflow utility_z_image_turbo_2k_upscaler.json'), which is a tautology. It does not state a specific verb or resource, making the tool's purpose completely unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (e.g., bundled_image_z_image_turbo_json). There is no context about appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
重启 ComfyUI 服务，等待服务恢复后返回「ComfyUI 服务已重启成功」
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the behavior: it restarts the service, waits for recovery, and returns a success message. No annotations are provided, so the description carries the full burden and handles it adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with a simple action, the description is complete. It specifies the action, behavior, and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description does not need to add parameter info. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: restart the ComfyUI service. It distinguishes from sibling tools that are image processing functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, but the name and purpose are self-explanatory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.0.5bundled_image_z_image_turbo_jsonbundled_qwen_image_2512_with_lora_jsonbundled_sensenova_jsonbundled_utility_birefnet_remove_background_jsonbundled_utility_z_image_turbo_2k_upscaler_jsonreboot_comfyuiEach tool has a distinct name referencing a specific workflow or action (e.g., 'image_z_image_turbo_json' vs 'qwen_image_2512_with_lora_json'), making them clearly distinguishable despite similar descriptions.
The five 'bundled_*_json' tools follow a consistent pattern, but 'reboot_comfyui' breaks the convention, introducing minor inconsistency.
With 6 tools, the server covers a focused set of workflows plus a utility action, which is well-scoped and avoids bloat.
The tools offer specific workflows but lack generic workflow execution or discovery capabilities, leaving notable gaps for broader image generation tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create, browse, remix, collaborate on, and run durable AI workflow nodes from MCP hosts.
MCP server for Qwen Image 3 AI image generation
MCP server for Hailuo (MiniMax) AI video generation
Remote MCP for AI video, image, music and speech generation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bookandmusic/mcp-comfyui'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
