workspace

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.

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.

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.

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.

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.

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.