comfyui-mcp

workspace

Manage local ComfyUI installations: inspect the active one, list detected ones, and set a default path for the MCP server.

Instructions

Inspect and manage ComfyUI workspaces (local installs). Driven by the action parameter:

action:"get" — Report the active ComfyUI workspace (mirrors comfy-cli which): the local installation path being used (from COMFYUI_PATH or auto-detection), the source of that path, any persisted default workspace, and the resolved API target the MCP server talks to.
action:"set_default" — Persist a default ComfyUI workspace path to the MCP config file (mirrors comfy-cli set-default). The value is stored under the OS config dir (e.g. ~/.config/comfyui-mcp/workspace.json) and reported by action:"get"/action:"list". Does NOT change the live API target. path is REQUIRED, e.g. {action:"set_default", path:"/opt/ComfyUI"}.
action:"list" — List known/auto-detected ComfyUI installations on this machine. Scans common install locations across macOS, Linux, and Windows and marks which one is active and which is the saved default.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "workspace"
  }
}

Input Schema

Name	Required	Description	Default
`path`	No	action:"set_default" — REQUIRED absolute path to a ComfyUI installation directory to remember as the default workspace.
`action`	Yes	Which workspace operation to perform. "get" and "list" take no other parameters; "set_default" requires `path`.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 30, 2026

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are present, so the description carries the full burden. It reveals key behavioral traits: set_default does NOT change the live API target, it stores the value in a config file under the OS config dir, and list scans common install locations across macOS, Linux, and Windows. It doesn't mention overwrite semantics or permissions, but covers substantial behavioral ground.

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

Conciseness4/5

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

The description is well-structured with a summary line followed by a bullet list of actions. Each sentence conveys important information without redundancy. It is slightly longer than minimal, but every part contributes to understanding the tool's behavior.

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

Completeness4/5

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

The description thoroughly covers the behavior of each action: what get reports, what set_default persists, and what list scans. Since there is no output schema, the description appropriately explains the essential return/effect semantics. Missing only minor details like exact output format or error handling, which are not critical given the tool's simplicity.

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 description coverage is 100%, giving a baseline of 3. The description adds meaningful value by explaining each action's semantics in detail (e.g., get mirrors comfy-cli which), clarifying that path is required for set_default, and providing an example usage. This exceeds the baseline with concrete guidance beyond the schema.

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 starts with 'Inspect and manage ComfyUI workspaces (local installs)', which clearly states a specific verb and resource. It distinguishes itself from siblings like comfy_cli, install_comfyui, and runpod by focusing on local installation path management. The three actions (get, set_default, list) further clarify its scope.

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

Usage Guidelines4/5

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

The description gives clear per-action context: get reports the active workspace, set_default persists a default, and list scans local installs. It does not explicitly name alternatives or exclusion criteria, but the 'local installs' qualifier implicitly disambiguates from remote/runpod tools. Clear context with no explicit exclusions warrants a 4.

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