ComfyUI MCP Skills
The ComfyUI MCP Skills server provides an AI-agent-oriented interface for ComfyUI, enabling seamless workflow execution, asset management, and job tracking. It dynamically generates MCP Tools with JSON Schema for each enabled workflow, allowing agents to trigger any configured workflow. Fixed tools include uploading local media assets (images, masks, audio, video) via comfyui.asset.upload, querying job status and output links via comfyui.job.get (with status tracking), cancelling queued jobs via comfyui.job.cancel (running jobs excluded), checking server health, and searching nodes/models. Output resource URIs can be directly reused as workflow inputs. The server supports stdio and authenticated HTTP, enforces security validations, and optionally offers an admin process for workflow modifications.
Allows approved runtime restart of ComfyUI instances deployed as Docker containers via a plan/commit control loop.
Optionally exports traces, metrics, and logs to an OpenTelemetry-compatible endpoint, including MCP tool call spans and application logs.
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., "@ComfyUI MCP Skillsrun the txt2img workflow with prompt 'a cat'"
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.
ComfyUI MCP Skills
让 AI Agent 以原生 MCP 工具安全地理解、执行和管理 ComfyUI。
ComfyUI MCP Skills 把 ComfyUI 工作流、作业、资产和控制平面投影为结构化 MCP Tools、Resources 与 Prompts。Agent 无需拼接 Shell 命令,也无需直接修改工作流 JSON,即可完成工作流发现、参数校验、执行、结果复用、诊断、实验和受控运维。
项目当前版本为 1.1.0(正式发布)。包元数据要求 Python >=3.10;CI 已验证 3.10–3.13,更新版本尚未纳入验证矩阵。
本项目不是 ComfyUI 自定义节点。它是独立运行的 MCP 服务,通过 HTTP 和 WebSocket 连接一个或多个 ComfyUI 实例。
文档
Related MCP server: comfyui-mcp
核心能力
领域 | 能力 |
工作流执行 | 每个已启用工作流参与动态工具目录;默认暴露 8 个,可通过 |
工作流理解 | 提供有界的节点、边、参数、输出和依赖语义视图,不向 Agent 暴露无界原始图 |
版本与编辑 | 不可变 Revision、结构化 diff、变更 plan/commit(AUTHORING 面,2026-09-04 起从 ADMIN 下放,工具名不变)、发布/回滚(ADMIN 面)、损失感知导入;高层 recipe(upscale/save/lora/controlnet 分支,经 |
作业与队列 | Job 查询、分页、取消、诊断、安全重试、队列查看与受控清理 |
资产与产物 | 上传、Asset/Artifact 目录、输出复用、跨服务器传输、内容摘要和完整血缘 |
批量实验 | Experiment plan/commit、矩阵与采样 Variant、预算约束、恢复、评分和结果固化 |
多服务器路由 | 根据 Deployment、依赖、队列、显存和 Policy 生成不可变执行计划,并以摘要绑定提交 |
管理与供应 | Server/Config 管理、依赖检查、审批、ComfyUI Manager 安装计划、Provisioning 恢复和审计闭环(append-only 事件 + |
运行时控制 | 明确区分单作业取消、队列操作、全局 interrupt;审批式重启执行闭环( |
MCP 原生交互 | Tools、Resources、Prompts、参数补全、资源订阅以及 provider-safe 工具名兼容模式 |
远程部署 | Streamable HTTP、静态 Bearer Token、RFC 7662 Token Introspection、Host/Origin/大小/并发边界 |
工作流、Revision、Plan、Job 和 Asset 的高级能力依赖对应 SQLite aggregate cutover。全新目录默认先使用兼容文件仓库;执行本教程只保证基础工作流发现、动态执行、上传和 job.get 查询,不能把高级控制平面能力当作已自动启用。job.list(历史分页)只在 SQLite run cutover 后挂载。
完整工具面和使用流程见功能文档。
架构
flowchart LR
Agent[AI Agent / MCP Host] -->|stdio 或 Streamable HTTP| Adapter[MCP Adapter]
Adapter --> Auth[Toolset 与 Scope 授权]
Adapter --> App[Application Services]
App --> Store[(SQLite Control Plane)]
App --> Gateway[ComfyUI Gateway]
Gateway -->|HTTP / WebSocket| ComfyUI[ComfyUI Server]
App --> Resources[MCP Resources / Prompts / Events]依赖方向固定为:
MCP / HTTP / CLI adapters
↓
Application services
↓
Domain contracts
↑
Infrastructure implementationsCLI 与 MCP 共用业务服务、ComfyUI Gateway 和持久化层;MCP handler 不启动 CLI 子进程。
快速安装
comfyui-mcp-skills 1.1.0 已进入正式发布流程(渠道与流程见 docs/RELEASING.zh-CN.md;PyPI 可见前请从 GitHub 安装或使用源码运行)。
方式一:从 GitHub 安装
python -m pip install "git+https://github.com/ShiroEirin/ComfyUI_MCP_Skills.git@main"方式二:源码开发安装
git clone https://github.com/ShiroEirin/ComfyUI_MCP_Skills.git
cd ComfyUI_MCP_Skills
uv sync --locked --extra dev安装后主要入口:
命令 | 用途 |
| 本地 stdio MCP 服务 |
| Streamable HTTP 服务 |
| 独立高风险管理面 |
| 保留策略与元数据清理 |
| 旧文件数据迁移演练 |
| 生产 aggregate 切换(需精确确认短语与备份) |
| 工具选择 Eval 基线 |
| 使用 OMP 配置的 |
| 兼容原 CLI |
最小项目配置
MCP 数据目录至少需要 config.json 和工作流目录:
my-comfyui-mcp/
├── config.json
├── data/
│ └── local/
│ └── txt2img/
│ ├── schema.json
│ └── workflow.json
└── uploads/config.json 示例:
{
"default_server": "local",
"servers": [
{
"id": "local",
"name": "Local ComfyUI",
"url": "http://127.0.0.1:8188",
"enabled": true
}
]
}最小 MCP 客户端配置
源码运行配置:
{
"mcpServers": {
"comfyui": {
"command": "uv",
"args": [
"run",
"--project",
"D:/github/ComfyUI_MCP_Skills",
"comfyui-mcp"
],
"env": {
"COMFYUI_MCP_DIR": "D:/path/to/my-comfyui-mcp"
}
}
}
}已安装命令时,可改为:
{
"mcpServers": {
"comfyui": {
"command": "comfyui-mcp",
"env": {
"COMFYUI_MCP_DIR": "D:/path/to/my-comfyui-mcp"
}
}
}
}Snow、Claude Code 或部分 OpenAI/Anthropic 兼容网关只接受 [A-Za-z0-9_-]+ 工具名。遇到 Invalid tools[n].name 时启用兼容模式:
{
"env": {
"COMFYUI_MCP_DIR": "D:/path/to/my-comfyui-mcp",
"COMFYUI_MCP_PORTABLE_TOOL_NAMES": "1"
}
}启用后,外部名称从 comfyui.job.get 变为 comfyui_job_get,服务内部仍按 canonical 名称分发。OMP 等支持点号名称的 Host 无需启用。
完整的 Windows、Linux、Snow、Claude Code、权限和 HTTP 配置见安装教程。
默认安全模型
stdio 默认使用:
principal: local-stdio
toolset: execution
scope: comfyui:execute因此默认只暴露执行所需能力。Authoring、Operations 和 Admin 必须显式配置 Toolset、Scope,并为高风险 Toolset 设置 COMFYUI_MCP_ENABLE_HIGH_RISK=1。
危险写操作遵循以下约束:
普通执行面与 Admin 管理面分离。
变更、安装、删除和全局操作优先采用 plan/commit。
plan digest、幂等键、主体和对象所有权共同约束 commit。
作业取消不会调用 ComfyUI 的全局
/interrupt。runtime.restart.plan提供影响快照与单次审批;runtime.restart.commit在审批后执行固定 controller 命令(systemd/docker/windows_service 适配器),期间/prompt提交被 drain/fence 拒绝(SQLite run store 门控;文件后端/fresh 只读预览)。远程上传、抓取、Host、Origin、正文大小、并发和速率均有边界。
基本使用流程
MCP Host 调用
comfyui.capability.search查找当前授权能力。Agent 选择
comfyui.run.<server>.<workflow>,参数由工作流 JSON Schema 校验。服务返回完成结果,或返回持久化 Job 标识供
comfyui.job.get恢复查询。输出以 Resource Link 暴露,可作为后续 image、mask、audio 或 video 输入。
失败时调用诊断与 retry plan/commit,而不是猜测并重复提交。
动态工具的 _execution 示例:
{
"prompt": "a cinematic portrait",
"_execution": {
"idempotency_key": "portrait-2026-08-05-01",
"wait": true,
"wait_timeout_seconds": 120
}
}超时不代表作业失败,也不会丢失作业。继续使用返回的 Job 或 prompt_id 查询即可。
Streamable HTTP
远程模式拒绝匿名启动,支持:
static:部署方配置的静态 Bearer Token。introspection:受众绑定的 RFC 7662 Token Introspection;端点必须为 HTTPS。
公网部署必须由反向代理终止 TLS。默认 process 限流模式拒绝 workers > 1;设置 COMFYUI_MCP_LIMIT_MODE=external 后使用 SQLite 共享限流后端,支持多 worker 的全局请求、并发与订阅配额。跨主机事件 fan-out 仍未交付。
详细环境变量和部署示例见安装教程。
开发与验证
uv sync --locked --extra dev
uv run ruff check src/comfyui_mcp_skills tests
uv run mypy src/comfyui_mcp_skills
uv run pytest -q
uv build当前本地交付验证:1036 passed, 1 skipped, 2 subtests passed(含 otel extra 下的 OpenTelemetry 集成测试——SDK traces/metrics 与 logs 桥接均真实执行;未安装 otel extra 的环境对应为 1029 passed, 8 skipped——6 个 SDK 集成测试、1 个 logs 桥接集成测试与 1 个 Windows 符号链接用例跳过)。这表示代码与 contract harness 通过,不等于任意新数据目录已经完成所有 aggregate cutover。CI 在 Windows 与 Ubuntu 上覆盖 Python 3.10–3.13。
项目状态与边界
已实现可靠执行、版本化工作流(含高层 recipe:upscale_image/save_image/lora_model/controlnet_apply.v1)、资产血缘、Experiment、诊断恢复、供应编排、多服务器路由、显式运行时控制(审批式重启闭环 + systemd/Docker/Windows Service 控制器)、RFC 7662 introspection、审计闭环(append-only 事件 + 有界导出)与可选 OpenTelemetry traces/metrics/logs(工具调用 span、计数与耗时直方图、logging 记录导出到 /v1/logs,COMFYUI_MCP_OTEL_ENDPOINT base URL 配置,otel extra 安装,见安装文档第 11 章)。workflow aggregate cutover 后,file-backed 的 comfyui.admin.workflow.set_enabled/delete 不再挂载(审计工具仍可用)。以下能力尚未作为正式产品能力交付:
Redis/NATS 多副本订阅总线。
多主机共享租约与跨主机配额(SQLite 共享限流仅限同主机多进程)。
Dependency Provisioning 需要维护者提供
dependency-catalog.json,否则只可检查而不能解析安装来源。MCP Tasks 扩展映射。
MCP Elicitation 审批。
本地单机部署边界
以下能力直接 proxy 引擎公共 API,不依赖控制平面存储:queue.list→/queue、server.health→/system_stats、node.list/describe→/object_info、model.list→/models、template.list/subgraph.list→/userdata、动态 run_*→/prompt、asset.upload→/upload。执行记录(job.*、幂等、Artifact 聚合、诊断/重试 lineage)是持久执行层而非引擎历史缓存——引擎 /history 只保留运行中/近期记录且引擎重启即失,因此 job.list 不退化为引擎历史 proxy。comfyui.local.plugins(本地会话)从 server 条目配置的 local_root 读取 custom_nodes 插件清单(双布局兼容 aki 的 ComfyUI/custom_nodes 与标准 custom_nodes,有界扫描 + reparse/symlink 拒绝 + TOCTOU 复核);云端/未配置会话返回 available:false 固定原因码。aki 等第三方整合包接入示例:
{
"servers": [
{
"id": "aki",
"name": "Aki ComfyUI",
"url": "http://127.0.0.1:8188",
"local_root": "D:\\ConfyUI-aki\\ComfyUI-aki-v1.6"
}
]
}本地 vs 云端节点信息策略:本地会话 = local.plugins(插件级能力)+ node.blueprint/list/describe(API 节点级);云端会话 = 仅 API 节点级(local.plugins 明确降级)。comfyui.workflow.visualize:已发布工作流有界 Mermaid 渲染(≤50 节点,SQLite Workflow store 门控);revision.diff 输出含 mermaid 视图(added 节点高亮),change.plan 的 diff 不含。comfyui.model.guidance:社区共识的模型家族采样器/调度器/steps/CFG/分辨率起点(9 个家族,静态数据,非引擎保证)。comfyui.job.history.suggest:基于本地运行历史的证据驱动参数建议(SQLite run store 门控、256 截断、仅本 principal 面可见)。本地查看跑图历史的最短路径是直接查询引擎 GET /history,或使用 CLI history 命令读取本地 data/ 目录;独立的只读引擎历史工具 comfyui.engine.history 已交付(扁平投影 prompt_id/status/outputs_count,8 MiB 有界解码,limit ≤50),避免污染 job.list 的 owner-bound 持久记录契约。控制平面按装配分层初始化:fresh 数据目录(无 data/control-plane.sqlite3)走轻量路径不建控制平面数据库,既有数据库完整初始化与升级;分层说明与本地 5 分钟上手见轻量引导文档。
持久化 schema 自 1.1.0 起版本化冻结:已发布迁移不可改写(改动在初始化时被拒绝,跨版本升级由迁移回归套件验证,覆盖 v1–v13 → 当前);升级自动应用且单向——新版本保证打开并升级任一已冻结历史前缀,新 schema 被旧版本代码打开时显式拒绝(fail-loud,不承诺降级),降级只能通过升级前备份恢复。升级前仍建议备份 config.json、data/ 和控制平面数据库。
License
Available Tools
3 toolscomfyui.asset.uploadC
Upload an authorized local image, mask, audio, or video file to ComfyUI and return an asset handle.
| Name | Required | Description | Default |
|---|---|---|---|
| purpose | No | image | |
| server_id | Yes | ||
| local_path | Yes | ||
| original_asset_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is a write operation. The description adds no additional behavioral context beyond stating it uploads files. It does not disclose potential side effects, authorization requirements, or error scenarios, leaving the agent uninformed.
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 sentence, which is concise but lacks structure or detail. It conveys the core function but omits crucial information about parameters and usage. Could be improved by breaking into clear sections.
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 4 parameters (2 required), an output schema present, and no explicit prerequisites or side effects, the description is incomplete. It does not clarify what 'authorized' means, how server_id and local_path should be specified, or what the asset handle looks like. The output schema may help, but the description itself lacks completeness.
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%, so the description must compensate. However, it provides no meanings for server_id, local_path, or original_asset_id. Only the purpose enum is vaguely hinted at by listing file types. This is insufficient for an agent to correctly populate parameters.
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 'Upload an authorized local image, mask, audio, or video file to ComfyUI and return an asset handle.' It uses a specific verb (upload) and resource (local files to ComfyUI) and clearly distinguishes from siblings like comfyui.job.get and comfyui.job.cancel, which deal with jobs.
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?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or conditions. It only states what the tool does without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
comfyui.job.cancelADestructiveIdempotent
Remove this principal's queued ComfyUI job; running jobs are safely rejected because ComfyUI interrupt is global.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt_id | Yes | ||
| server_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | Yes | |
| status | Yes | |
| outputs | Yes | |
| client_id | Yes | |
| prompt_id | Yes | |
| server_id | Yes | |
| workflow_id | Yes | |
| idempotency_key | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, idempotentHint=true), the description explains that running jobs are 'safely rejected because ComfyUI interrupt is global,' adding valuable behavioral context about why the tool cannot cancel running jobs.
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, well-structured sentence that conveys the core purpose and a key behavioral caveat without any superfluous 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?
Given the tool's simplicity (two self-explanatory parameters) and the presence of an output schema, the description covers the primary use case and constraints. Missing parameter details are a minor gap, but overall it's fairly complete.
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?
The description does not discuss either parameter (prompt_id, server_id). With 0% schema description coverage, the agent must infer meaning from parameter names alone, which is insufficient for reliable use.
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 ('Remove') and the resource ('this principal's queued ComfyUI job'), differentiating it from sibling tools get and upload. It also explains behavior for running jobs, leaving no ambiguity.
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?
The description implies usage for cancelling queued jobs and notes that running jobs are rejected safely, providing context for when the tool will succeed. However, it does not explicitly state when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
comfyui.job.getARead-only
Get durable ComfyUI job status and output resource links.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt_id | Yes | ||
| server_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | Yes | |
| status | Yes | |
| outputs | Yes | |
| client_id | Yes | |
| prompt_id | Yes | |
| server_id | Yes | |
| workflow_id | Yes | |
| idempotency_key | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the tool is known to be safe. The description adds value by specifying that the tool provides 'durable job status and output resource links', which gives context beyond annotations.
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 that is front-loaded with the core purpose. Every word is necessary and there is no extraneous 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?
The description covers the basic function but does not elaborate on prerequisites, side effects, or how to interpret the output. Given the presence of an output schema, the lack of return value explanation is acceptable, but more context on usage would improve completeness.
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%, so the description must compensate, but it does not explain the purpose or format of 'prompt_id' and 'server_id'. Users must infer that these identify the job, which is insufficient.
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 verb 'Get' and the resource 'durable ComfyUI job status and output resource links'. It effectively distinguishes from siblings like comfyui.job.cancel (cancel) and comfyui.asset.upload (upload).
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?
The description implies that the tool is for retrieving status and links, but it does not explicitly state when to use it over alternatives or mention prerequisites. The mention of 'durable' hints at a specific use case but lacks clarity.
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. Dates show when Glama detected each change.
3 tool updates
v1.0.0- First observed
comfyui.asset.upload - First observed
comfyui.job.cancel - First observed
comfyui.job.get
TDQS
Each tool targets a distinct action: get job status, cancel job, and upload asset. No overlap or confusion between them.
All tool names follow a consistent pattern: resource (job or asset) followed by action (get, cancel, upload), using dot notation.
Only 3 tools is minimal but may be appropriate if the server is narrowly scoped to job status, cancellation, and asset upload. However, it feels underdeveloped.
Obvious gaps: no tool to create or run a ComfyUI job, and no tool to list jobs or download results. Users can upload assets but cannot initiate a job using them.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Remote MCP server for RunComfy Serverless API (ComfyUI): deployments and async inference.
Remote MCP server exposing SMI Aware tools, resources, and skills over Streamable HTTP.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
Related MCP Servers
- FlicenseAqualityDmaintenanceMinimal MCP server that wraps ComfyUI HTTP routes enabling LLM clients to inspect server status, models, features, node metadata, submit workflows, manage queue/history, interrupt runs, and upload images.11-
- FlicenseNot gradedqualityCmaintenanceMCP 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.-

RunComfy MCPofficial
AlicenseNot gradedqualityAmaintenanceMCP server for RunComfy's Serverless API (ComfyUI) that enables managing deployments, running inference, and retrieving results from AI assistants like Claude and Cursor.MIT- FlicenseNot gradedqualityCmaintenanceWindows-native MCP server for a local ComfyUI portable package. It enables listing, validating, and running ComfyUI workflows via the loopback HTTP API.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ShiroEirin/ComfyUI_MCP_Skills'
If you have feedback or need assistance with the MCP directory API, please join our Discord server