ComfyUI MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.52.83
Disambiguation4/5
Most tools have clearly distinct purposes, but the large number creates some overlap risk—e.g., install_comfyui's update_all vs install_custom_node's update, or generate_image vs enqueue_workflow for starting renders. The detailed descriptions help differentiate, but an agent must read them carefully.
Naming Consistency3/5
The majority follow verb_noun (save_workflow, get_image), but many deviate: noun-only tools (queue, runpod, apps), noun_noun compounds (node_pack, model_metadata), and awkward structures (train_start, train_prepare_dataset). This mix makes the naming somewhat predictable but not uniform.
Tool Count2/5
With 40 tools, this server is well beyond the 25+ threshold considered 'too many'. While the broad scope (workflows, generation, models, training, runpod) justifies some complexity, the count is excessive and would be better split into focused servers or consolidated.
Completeness5/5
The tool surface is exceptionally complete, covering CRUD for workflows, models, custom nodes, training datasets/jobs, and runpod management. There are few obvious gaps for the stated purpose, and the server even includes utilities like calculate and batching.
Average 4.7/5 across 40 of 40 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 39 of 40 community issues answered or closed in the last 6 months
- 2407 commits in the last 12 weeks
- Last stable release on September 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does well: it discloses that models_download runs for minutes and is gated on an idle-liveness timeout to avoid kills, that skills install/uninstall default to dry-run unless apply=true, that workflow_run is async unless wait=true, and that some actions fall back to server endpoints without the CLI. These are important behavioral traits beyond just the operation name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely long with substantial repetition. For example, the action list in the description mirrors the enum values in the schema, and many actions are listed with similar phrasing like 'action:"..." — required for...' which duplicates schema properties. The structure is a flat job list without grouping headers or a summary, making it hard to scan quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (31 params, 26 actions), the description covers each action's purpose and required params, and it explains key behaviors like fallbacks, dry-runs, and timeouts, which is commendable. However, the lack of a user mapping for skills (despite mentioning the skill names), and no info on return values (output schema absent) leaves some gaps. It does not address relationships with sibling tools beyond two mentions, so completeness is average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 some context by grouping actions on parameters (e.g., 'promptId required' for several actions) and clarifying defaults like 'relativePath' defaults to models/checkpoints. However, it does not systematically link each parameter to its action family; it often only repeats the required/optional flags already in the schema, and some parameters like 'where' have no additional explanation beyond the schema enum description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists many actions with specific verbs and resources (e.g., 'status — Inspect the comfy-cli integration', 'jobs_wait — Wait for jobs'), clearly specifying each operation. It differentiates from siblings by mentioning 'search_nodes' complements 'search_custom_nodes' and references other tools. However, it does not explicitly distinguish from all 38 sibling tools, and the purpose overall is a toolbox covering many functions, diluting a single clear purpose.
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?
Provides explicit when-to-use guidance: e.g., 'Call this before local CLI operations when workspace or server routing is uncertain' for status, and 'Complements search_custom_nodes' for search_nodes. It also clarifies when fallback occurs. However, it lacks explicit 'when not to use' statements for most actions, and alternative tools are mentioned only for search_nodes, not comprehensively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states that the result is exactly what the underlying tool returns, which is a useful behavioral note. However, it doesn't disclose potential side effects, errors, or the dynamic nature of execution. The description is adequate but lacks depth.
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 two short sentences, front-loaded with the main purpose, and includes essential operational detail about parameter passing and return behavior. No wasted words.
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?
Given that the tool's behavior is dynamic (executing arbitrary tools), the description covers the essential invocation details: name, args, aliases, and the fact that the result is passthrough. The schema also documents aliases fully. While it doesn't mention error handling or edge cases (e.g., unknown tool), for a wrapper tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage across the parameters, including descriptions for name, args, and aliases. The description adds a bit by explaining the args object matches the describe_tool schema, and a JSON string is accepted. This supplements the schema, but the schema already covers the semantics well, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute a tool from the catalog by name' and how parameters are passed. It distinguishes itself from siblings like list_tools and describe_tool by focusing on execution, though it doesn't explicitly mention alternatives.
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 context on when to use: when you need to execute a tool from the catalog, providing the tool name and parameters. It doesn't explicitly contrast with alternatives like list_tools or describe_tool, but the purpose is clear enough to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility, and it delivers: it discloses success semantics ('success is true only when nothing failed AND nothing is still pending'), partial-install behavior in the partial field, the Manager-queue caveat, local path resolution order, and remote routing through ComfyUI-Manager. This is detailed, non-obvious behavior that an agent needs to know before invoking.
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 dense but every clause earns its place: it covers input forms, item categories, local/remote path behavior, per-item statuses, success criteria, partial installs, and the restart warning. It is not a terse two-liner, but the complexity of the tool justifies the length and the information is grouped logically; only minor trimming of repeated 'LOCAL/REMOTE' details would improve it.
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?
This is a complex tool (nested manifest object, local vs remote modes, multiple item types, partial-failure states) with no output schema, yet the description covers what happens per item, how success is computed, what partial installs look like, and what follow-up action is needed. That makes the description sufficient for an agent to apply the tool correctly and interpret its result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; each parameter (pack, path, manifest) is already documented in the schema. The prose adds file-format context and environment-dependent resolution behavior, but it does not substantially enrich individual parameter semantics beyond what the schema and its param descriptions already provide.
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 opens with a specific action and resource: 'Apply a ComfyUI setup manifest from an inline object or .json/.yaml/.yml file.' It then enumerates what the tool composes (custom-node installs, model downloads, pip packages, apt entries as skipped), making the tool's scope unambiguous and distinguishing it from single-purpose siblings like download_model or install_custom_node.
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 operational guidance: local vs remote behavior, why some entries are skipped, and the warning not to restart ComfyUI until entries settle. It also indirectly signals when apply_manifest is appropriate (bulk manifest application) but does not explicitly name alternative tools or carve out when-list_packs/install_custom_node should be used instead, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior (freeing VRAM, unloading models) and optional toggles, but doesn't mention side effects like slower reload on next generation.
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?
Two concise sentences with no redundancy. The example clarifies usage without padding.
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?
For a simple utility tool, the description provides enough context on when and how to use it. The lack of output schema is acceptable given the straightforward behavior, though a note about impact on subsequent runs would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with clear descriptions. The description's mention of optional unloads directly mirrors the schema, adding minimal extra meaning beyond what's already present.
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 opens with 'Free GPU VRAM by unloading cached models from ComfyUI,' clearly identifying the verb and resource. It distinguishes from siblings like generate_image or get_system_stats by focusing specifically on VRAM management.
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?
Provides explicit usage context: 'between generation runs with different model families' and 'when running low on VRAM.' It also explains optional modes (only models or only memory), giving clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries a moderate burden. It describes what the tool returns ('full description and JSON Schema') and notes it comes 'from the catalog,' implying a read-only lookup. It does not explicitly state 'no side effects' or discuss error behavior, but for a trivial describe tool, this is acceptable and adds useful context about session-based best practice.
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?
Two sentences, zero filler. The primary purpose is front-loaded in the first sentence, and the second sentence delivers a crucial usage directive. Every word 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?
The tool is simple (no output schema, no annotations, two self-explanatory parameters). The description fully covers its purpose, its role in the workflow, and hints at return content. Given the low complexity, this is complete and well-contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage: 'name' is described as 'Exact tool name from list_tools' and 'tool_name' as 'Alias for name.' The description adds no additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.
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 a specific verb and resource: 'Get the full description and JSON Schema of one tool from the catalog.' This distinguishes it from siblings like list_tools (which lists all tools) and call_tool (which invokes a tool). The purpose is unambiguous and non-tautological.
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 when-to-use guidance: 'Always call this before the first call_tool of a tool you haven't used in this session.' This directly instructs the agent on the proper workflow and implies it should be used as a prerequisite for unfamiliar tools, making the usage context crystal clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the output format (token-light catalog, grouped by category) and implies a read-only, non-side-effect operation. It could mention absence of destructive behavior, but for a list tool this is adequate and adds value beyond raw schema.
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?
Two sentences: first states purpose and output format, second gives workflow guidance. Every word is purposeful, no redundancy, and the most critical information (what and how to start) is front-loaded.
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 simple listing tool with no output schema, this description fully covers what the tool returns (catalog of tool names and summaries), its organization (grouped by category), and the intended next steps. It is complete for the tool's purpose and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (search, category) have descriptive text in the schema. The description does not add extra parameter meaning, but it doesn't need to because the schema completely explains them. Baseline 3 is appropriate.
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 explicitly states the tool lists every comfyui-mcp capability as a token-light catalog with tool names and one-line summaries, grouped by category. This clearly distinguishes it from siblings by positioning it as the top-level entry point, and precisely names the resource and action.
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 says 'Start here' and then instructs to use describe_tool for parameters and call_tool to run tools, giving explicit sequential guidance on when and how to use this tool relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It openly discloses asynchronous behavior ('Every action enqueues on the connected ComfyUI and returns the prompt_id immediately'), model auto-selection, default filling, error handling (e.g., 'returns an actionable error if the checkpoint is missing'), output locations, and limitations (e.g., 'This minimal path omits the synchronized audio + stage-2 spatial upscale'). It even explains nuanced behaviors like strength semantics ('higher strength means MORE adherence to the start frame but LESS motion (1.0 can freeze the clip)') and seed re-randomization. This is exemplary transparency.
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 long, but given the tool's complexity (9 actions, 52 parameters), every section earns its place. It front-loads the core behavior (enqueue, prompt_id) and then organizes each action into a clear block covering requirements, defaults, outputs, and limitations. It is dense but not bloated, though it could be slightly tightened by trimming redundant schema echoes. Well-structured with actionable separators.
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?
The tool is highly complex and has no output schema, so the description must explain what the tool returns and how to follow up. It states the immediate return (prompt_id) and the eventual asset_id via notification. For different actions, it explains where results land (e.g., 'The video is written under output/video/ — find it with get_image (action:"list_outputs")') and how to poll for 3D results ('Poll queue (action:"status") / get_history (action:"list")'). It also covers prerequisites, errors, and limitations for each action, making it a complete reference for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema already documents every parameter with action-specific descriptions, defaults, and requirements (e.g., strength descriptions for video and controlnet). The tool description adds some cross-action narrative (e.g., checkpoint differences per action) but largely restates what the schema already conveys. It does provide context like 'auto-selecting a local checkpoint when none is given' but that is also in the schema. No significant extra meaning 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 opens with a clear verb-resource statement: 'Generate media from a prompt or an existing image — the high-level entry points that build the graph for you.' It then enumerates nine distinct actions (image, audio, video, 3d, controlnet, ip_adapter, regenerate, upscale, remove_background), each with specific behavior. It also distinguishes itself from lower-level alternatives by noting 'For full control over the node graph, use create_workflow + enqueue_workflow instead.' This fully establishes what the tool does and how it differs from siblings.
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 when-to-use and when-not-to-use guidance. It names alternatives for specific cases: 'For full control over the node graph, use create_workflow + enqueue_workflow instead' and 'To re-run from execution HISTORY rather than a registered asset, use enqueue_workflow (action:"rerun")'. It also states prerequisites for each action (e.g., 'Requires a running ComfyUI with the corresponding model files installed', 'Needs the LTX-2.3 models (~24-46GB): install with apply_manifest ...') and notes fallback behavior when prerequisites are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses safety/behavioral traits: external API calls, server-side execution, required Comfy account/API key, paid credits, immediate return of prompt_id, empty list when disabled, and explicit 'Do NOT pass auth credentials in inputs'. This goes well beyond the schema.
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 longer than average but organized by action bullets, with the core purpose in the first sentence. Each section adds necessary details; slight repetition (e.g., multiple 'Use action' instructions) is acceptable given the multi-action complexity.
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 3-action tool with nested inputs and no output schema, the description covers list results, schema contents, generate's immediate prompt_id return, auth behavior, and credit implications. It is sufficiently complete for an agent to select and invoke correctly.
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 input schema already covers all five parameters (100%), and the description reinforces action-parameter interdependencies: action:list takes filter, schema/generate require class_type, generate requires inputs and optional disable_random_seed. It also adds semantic detail like filter matching against class_type/display/category.
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 opens with a specific verb+resource ('Discover and run hosted partner/API nodes on the connected ComfyUI') and then enumerates three distinct action modes (list/schema/generate), clearly distinguishing this from sibling tools like generate_image by emphasizing external providers and paid credits.
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?
It provides strong context: 'Start here to find a class_type', 'Use action:list first', 'Use action:schema to discover valid inputs', and explicitly frames generate as enqueuing a remote API run. It doesn't name sibling alternatives as exclusions, but the paid-credit vs local-GPU contrast implies when to prefer this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the behavioral contract: it blocks for minutes, always returns eventually, warns about double-filing on retry, explains pending:true and job_id behavior, covers fallback to a prefilled URL, and describes what outputs to surface (agent_message/upgrade advice). This goes far beyond a typical description and the absence of annotations makes this transparency essential.
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 long but every sentence carries critical operational detail: timing, retry dangers, fallback paths, and versioning. It is front-loaded with the core purpose and then systematically covers behavioral nuances. While it could be tightened, the length is justified given the tool's complexity and the high stakes of misuse (double-filing).
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?
Even without an output schema, the description explains all possible return scenarios: triage result, pending flag, job_id, prefilled URL, and agent message. It also covers edge cases like unreachable worker and third-party repos. For a tool with this many parameters and complex asynchronous behavior, the description is exceptionally complete.
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 schema already covers all 7 parameters with 100% coverage, so the baseline is 3. The description adds valuable semantic context by insisting on passing mcp_version and panel_version from the environment, detailing the body's required contents (exact error text, frontend version), and clarifying repo choices. This extra guidance elevates it to 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 opens with a specific action: 'File or triage a GitHub issue for a bug/problem you hit', naming the resource (GitHub issue) and distinguishing it from all sibling tools (none are issue-related). It further details the triage behavior for our repos versus third-party repos, making the purpose unmistakable.
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 clearly explains when to use the tool (for bugs/problems in ComfyUI ecosystems) and gives detailed scenario-specific guidance: for our repos it uses the AI triage worker, for third-party repos it returns a shareable URL. It also provides strong operational guidance like 'ALWAYS pass mcp_version and panel_version' and warns against blind retries. It does not explicitly mention alternative tools, but the context is strong enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries full burden and delivers: it discloses destructive behavior ('Kills the process tree', 'Anything queued or rendering is lost'), operational sequencing (captures config, waits for port free, polls for bounded readiness), and preconditions ('requires ComfyUI-Manager present and its security level permitting the reboot'). This level of side-effect and failure disclosure is exemplary for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is logically organized by action and front-loaded with 'Control the lifecycle of the ComfyUI server process', but it is dense, with deeply nested clauses and a bulky middle paragraph on the restart path that mix remote behavior, env vars, and recovery rationale. The leading dash and double-hyphen formatting is also slightly awkward. It earns its length better than most, but tighter scoping would help scannability.
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?
For a side-effecting control tool with three actions, local/remote differences, an env-var override, and a reference to the sibling 'queue' tool, the description covers the operational surface remarkably well: prerequisites, side effects, failure modes, and boundaries (bounded readiness, local-only for start/stop). The only gap is that no return/response format is described, though for a fire-and-forget process control tool this is a minor omission.
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% for the single 'action' parameter, so the 3-baseline applies, but the description goes well beyond the schema by explaining consequences of each enum value (remote vs local applicability, state persistence across stop/start, readiness polling) and the environment-variable override behavior. The schema's own param description is also solid, making this a well-covered parameter end-to-end.
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 opens with a specific verb+resource — 'Control the lifecycle of the ComfyUI server process' — and enumerates three clearly bounded actions (restart, start, stop) with distinct behavioral contracts. The trigger conditions (reload custom nodes, WEDGED job escalation, externally managed installs) distinguish this lifecycle tool from siblings like 'queue' or 'comfy_cli' without needing to name them all.
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 frames when each action is appropriate: restart is 'the normal way to reload newly installed custom nodes' and 'the escalation when queue (action:"cancel") reports a job WEDGED', explicitly naming the sibling tool. It also gives conditional alternatives (COMFYUI_RESTART_COMMAND for containers/systemd, ComfyUI-Manager over HTTP for remote) with exact prerequisites, leaving no doubt which path applies where.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: safe zero-dependency evaluator (no eval), numbers-only restriction, batch semantics, variable assignment persistence, separator rules (including the comma caveat), full operator/function list, and RNG seeding behavior (seed echoed back). This goes far beyond basic disclosure.
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 long but every section earns its place: purpose, safety, syntax, operators/functions, and three practical examples. It is front-loaded with the core purpose and uses clear formatting (paragraphs, ells, code blocks) to remain scannable despite its length.
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 richly covers the input side—syntax, operators, functions, seeds, variables—and mentions seed echoing. However, it never explicitly states the output format/return shape (e.g., a list of results). For a calculator tool this is mostly inferable, but a one-sentence note on the return structure would fully close the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description, but the description adds significant semantic value: it explains the spec syntax (newline/semicolon separation, assignment, comma-as-argument-separator), provides examples, and details the RNG seed behavior and variable environment. This meaningfully exceeds what the schema alone provides.
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 opens with a specific verb+resource: 'Evaluate a batch of math expressions exactly.' It clearly distinguishes the tool from all sibling tools (workflow/image/ComfyUI operations) and clarifies it works without ComfyUI. The scope is precisely defined.
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 clearly states when to use it: 'works even in cloud mode or when ComfyUI is down' and notes it's 'handy for the arithmetic agents get wrong token-by-token.' It implies it is the go-to for safe arithmetic evaluation, though it does not explicitly name alternatives or say 'when not to use.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it repeatedly states all actions are READ-ONLY and 'nothing here mutates anything.' It also notes error conditions ('Errors if the server is unreachable') and describes what each action returns (e.g., raw /system_stats JSON, aggregated health signals). This is comprehensive for a diagnostic tool.
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 long but well-structured with a clear front-loaded purpose and bulleted action breakdowns. Every sentence serves a purpose: defining each action, its parameters, and its use case. The length is justified by the tool's multi-mode nature, and the structure aids scannability.
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?
Given the complex three-action tool with no output schema, the description is remarkably complete. It specifies inputs, outputs, default values, error behavior, and use-case context for each action. It even covers edge cases like 'empty dropdowns from a misconfigured extra_model_paths.yaml.' No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not materially add to the parameter semantics already present in the schema; it repeats the action-scoped parameter explanations (e.g., 'max_lines tails the end (default 100)'). It does clarify that 'stats takes no other parameters,' but this is also in the action parameter description. No significant value beyond 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 clearly states the tool's purpose: 'Inspect the connected ComfyUI server: what it is running on, what it has logged, and whether it is healthy enough to dispatch work to.' It then enumerates three distinct actions (stats, logs, health) with specific verbs and outcomes, effectively distinguishing this tool from siblings like get_history or get_image.
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 when-to-use guidance for each action: stats for confirming connectivity and checking VRAM before enqueuing large workflows, logs for debugging execution errors, and health as a pre-flight diagnostic before batch runs or after unexpected failures. It also emphasizes the read-only nature, helping the agent choose this over mutating alternatives like restart_comfyui or clear_vram.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full transparency burden and does so thoroughly. It discloses that local and remote status reporting differ, that a failed probe is reported as unknown rather than no, that assess only emits a recommendation when all facts are known, and that apply requires confirm for restarts/downloads. It even explains restart_comfyui's behavior of replaying previous argv without injecting new flags.
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 long but well-structured with a high-level overview followed by bullet per action. Each sentence adds substantive information, though some details like the proof path in panel_kitchen could be trimmed or moved. The format makes it scannable despite the length.
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?
For a multi-action tool with no output schema and no annotations, the description covers operations, parameter requirements, alternatives, and edge cases in depth. The main gap is that it doesn't explicitly describe the exact response/return format for each action, though it implies what each returns (recommendations, status details). Overall it is nearly complete for safe invocation.
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 the baseline is 3, but the description adds meaningful context per action: status takes no other parameters, assess takes workflow, and apply takes recommendation_id and confirm. It also clarifies workflow format (API or UI JSON) and gives example recommendation IDs, which goes beyond the schema descriptions.
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 opening sentence clearly states the tool's purpose: 'See what comfy-kitchen can do on this GPU, find where a graph is leaving it on the table, and apply the faster path.' The three actions (status, assess, apply) map directly to that purpose, and the description distinguishes it from siblings by focusing on comfy-kitchen-specific features like INT8 attention and fp8 backends.
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 explicitly says 'For the open canvas use panel_kitchen,' routing to an alternative. It also specifies when to use each action and gives concrete conditions for assess recommendations (e.g., 'bf16 UNETLoader + GPU fp8 + kitchen present → fp8_e4m3fn_fast') and apply requirements (confirm for restarts/downloads vs widget edits). This is explicit when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses read-only status of 'doctor,' idempotency and time cost of 'bootstrap,' and docker-daemon requirement for 'build_image.' It also notes side-effect boundaries ('Touches no dataset and no job') and environment details (HF_TOKEN, NVIDIA Container Toolkit). Lacks explicit failure/error behavior, but this is already generous.
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 long but organized by action with bullet-style formatting. Every sentence contributes operational detail (prereqs, timing, idempotency), though it could be tightened without losing information. Front-loaded with the core purpose before diving into actions.
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 tool with 4 parameters, 3 action modes, and no output schema, the description is remarkably complete. It covers purpose, when to use each action, prerequisites, runtime expectations, and what is touched/not touched. This is more than sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3, but the description goes well beyond by explaining each action's parameter interplay, defaults, and constraints. For example, it clarifies that 'doctor' takes no other parameters, 'bootstrap' takes target/pod_id, and 'build_image' takes aiToolkitRef with default behavior.
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's role: 'Preflight and set up the TRAINER ITSELF — the docker/GPU/venv machinery every training job needs.' It further distinguishes from siblings by explicitly saying 'Touches no dataset and no job,' marking it as distinct from training job and dataset tools.
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?
Provides explicit when-to-use guidance: 'Run this first when a training start fails' and 'Needed before a target "pod" train_start on a fresh pod.' It also frames the build_image action as 'The docker alternative to action:"bootstrap"' with actionable prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that the tool does not read the live canvas, that conversions round-trip losslessly, that from_dsl emits advisory warnings only when ComfyUI is reachable, and marks experimental actions. It doesn't explicitly state side-effect safety (e.g., read-only), but the nature of the actions and these caveats offer good behavioral insight.
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 long but extremely well-structured, front-loading the core purpose and the key limitation before a bullet list of actions. Each action is described in one compact sentence with prerequisites and output types. No filler or repetition; all sentences earn their 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?
Given 8 parameters, 5 actions, no annotations, and no output schema, the description compensates thoroughly. It covers every action's purpose, requirements, and output format, plus edge cases like auto-detection of API/UI format and lossless round-tripping. The absence of an output schema is mitigated by explicit descriptions of each action's result (diagram, text listing, structured summary, DSL).
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% and each parameter already has a detailed description. The tool description adds value by tying parameters to actions, e.g., 'to_dsl expects API format (node ID -> {class_type, inputs})' and clarifying which action requires which parameter. This goes beyond the schema's per-field descriptions, providing cross-parameter semantics.
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 opens with a specific verb+resource: 'DRAW a diagram of, or convert, workflow JSON you PASS IN.' It immediately distinguishes from siblings by noting it does NOT read the live canvas and directs to panel_graph_outline for that case. The action list further clarifies each mode (render, render_hierarchical, mermaid, to_dsl, from_dsl), making the tool's purpose unmistakable.
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 explicitly states when to use an alternative: for 'show me what's on the canvas' use panel_graph_outline. It also gives action-specific guidance, e.g., render_hierarchical is what you want past ~20 nodes, and to_dsl/from_dsl are experimental. This provides clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It does so extensively: read-only actions are marked, run returns prompt_id and patches values, unknown keys fail loudly, omitted inputs use defaults, import does not install deps and re-importing conflicts, and registry_url has SSRF concerns. This is model-level 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 long but well-structured with a clear introduction and action-by-action bullets. Each sentence provides unique value: no redundancy, and every behavioral nuance (read-only flags, defaults, conflict warnings) earns its place. The format makes it easy for an agent to scan and extract needed information.
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?
Given the tool's high complexity (5 actions, 7 params, nested objects) and the absence of an output schema, the description is remarkably complete. It specifies return values for each action (manifests, prompt_id, status/outputs), covers edge cases (deps not installed, SSRF, unknown keys), and leaves no major gaps. The agent has everything needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning beyond the schema. It explains that values are keyed by '<nodeId>.<widget>' with an example, that app_id has different requirements per action, and that registry_url must be allowlisted to avoid SSRF. This enriches the schema and provides operational context.
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 opens with a specific definition: 'Micro-apps on this ComfyUI (panel Apps feature): named workflows packaged for one-click runs.' This clearly distinguishes it from sibling workflow tools like enqueue_workflow or save_workflow. The five actions are each described with specific verbs and resources, fully specifying the tool's purpose.
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 provides detailed guidance for each action, including which parameters are required and the behaviors of list/get/run/run_status/import. It does not explicitly say 'when not to use' or compare to sibling tools, but the action-based structure gives clear context for when to invoke each operation. It also warns about import conflicts and missing deps, which informs user decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it explains the underlying mechanism (enables half, disables rest), mentions the preferred API and fallback to .disabled directory suffixes, warns that a restart may be needed, and details the state machine transitions. This goes well beyond a minimal description and gives the agent a clear model of side effects and prerequisites.
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 longer than typical but every sentence contributes essential information about the state machine, actions, and constraints. It is well-structured with a clear overview followed by per-action details, and the front-loaded purpose makes the tool's intent immediately clear. No redundant filler is present.
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?
Given the tool's complexity (state machine, side effects, fallback behavior), the description is remarkably complete. It covers all five actions, their prerequisites, the session lifecycle, the restart caveat, and the information returned by 'status'. Since there is no output schema, the explicit description of 'status' results is especially valuable. The description leaves no significant gaps for using the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant semantics beyond the schema by explaining each enum value's effect within the state machine (e.g., what 'good' does to candidate sets and when it reports the culprit). It also clarifies that all actions are argument-free and that 'good'/'bad' require an active session, which is not evident from the schema alone.
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 opens with a specific verb and resource: 'Binary-search (git-bisect style) over installed ComfyUI custom nodes to find which one causes a problem.' This clearly distinguishes it from sibling tools like search_custom_nodes or install_custom_node. The state machine explanation further clarifies its unique role.
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 provides a clear when-to-use context for each action, such as 'Use to abort a bisection or restore the installation after the search completes' for reset, and notes that 'good'/'bad' require a prior 'start'. It does not explicitly name alternative tools, but the context strongly implies the appropriate scenario, so it lacks only the explicit exclusion guidance for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral aspects: read-only vs write operations, persistence semantics (runtime vs config/file), restart behavior, availability constraints (Comfy Cloud mode), type coercion absence, and return value details (e.g., for set_ui). It even explains the precedence of settings and how per-call MCP args override defaults.
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 long (over 500 words) but structured per action with bullet points. Every sentence adds necessary detail given the complexity of four distinct actions. It is front-loaded with the core purpose and then elaborates systematically. While not minimal, the length is justified by the tool's multi-action nature.
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?
Given the tool's complexity (6 parameters, 4 actions, two stores) and the absence of an output schema, the description covers most essential context: it explains precedence, persistence, availability, and known IDs. However, it omits the return structure for 'get' and 'get_ui' actions (it mentions a merged view but not its schema, and lists settings but not their format). Minor gap, but overall very complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant value beyond the schema: it ties each parameter to specific actions, explains required/optional contexts (e.g., 'REQUIRED for action:"set_ui"'), provides enumerations of known IDs, and clarifies type handling (booleans/numbers not coerced). This goes well beyond what the schema alone conveys.
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's purpose: reading and writing settings, with explicit differentiation between two separate stores (generation defaults vs ComfyUI UI settings). It uses specific verbs for each action and distinguishes the tool from siblings by covering unique functionality.
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 use each action, including when not to (e.g., 'Not for Comfy.* UI ids — those go through action:"set_ui"'). It outlines prerequisites (e.g., 'Requires a reachable local or remote ComfyUI') and clarifies context for each of the four actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does this thoroughly: it flags mutating actions ('MUTATING: this is the ONE action on this tool that INSTALLS anything', 'MUTATING: it WRITES to the read-through skill cache'), notes read-only actions ('READ-ONLY — it installs nothing', 'READ-ONLY — the way to INSPECT what a pack will install BEFORE calling the mutating apply_manifest'), and discloses side effects like 'Installing a pack downloads and runs third-party code (and may pull large files) on the connected ComfyUI host' and 'a ComfyUI restart is typically needed before new nodes load.' It also explains the 'externalApiNodes' nuance and the 'unknown' runtime classification, which is critical for cost transparency.
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 long (over 1000 words) but densely packed with essential information. It is structured with clear action headers and bullet points, making it scannable. Each sentence earns its place: it covers purpose, usage, side effects, and alternatives for each action. However, it is verbose in places, e.g., the 'check_runtime' section repeats the 'externalApiNodes' explanation twice. It could be tightened without losing value, but the structure is exemplary for a multi-action tool.
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?
Given the tool's complexity (10 actions, 8 parameters, no output schema, no annotations), the description is remarkably complete. It covers all actions, parameter interactions, side effects, cost implications, and alternatives. It even explains the return structure for 'check_runtime' and the 'externalProviders' field. The only minor gap is that it doesn't describe the exact return format for 'list' or 'skill_list', but the output schema is absent and the description gives enough context for the agent to infer. The description fully compensates for the lack of annotations and output schema.
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%, so the baseline is 3. The description adds significant value beyond the schema: it explains the action-specific parameter requirements (e.g., 'action:"check_runtime" takes `pack` OR `graph`'), clarifies the meaning of 'name' for different actions, and provides examples ('e.g. "krea2-txt2img-manual"'). It also explains the 'externalProviders' field in the return value, which is not in the schema. However, some parameter semantics are only implied (e.g., 'refresh' is described in the schema but the description adds the 'bypass the read-through cache' context, which is already in the schema description). The description does not add much for 'install_in' beyond the schema, but overall it enriches the parameter understanding.
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's purpose: 'Bundled ComfyUI knowledge — installer packs, model-family skills, workflow templates — plus the two workflow-readiness checks.' It enumerates ten distinct actions, each with a specific verb and resource (e.g., 'List the bundled installer packs under packs/', 'Return a bundled pack's ready workflow.json graph'). It distinguishes from siblings by naming alternatives like 'install_comfyui apply_manifest' and 'panel_load_workflow', and by referencing the 'panel_*' tools for canvas operations.
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 when-to-use guidance for each action. For example, it says 'When asked to "set up / build a <model-family> workflow", PREFER applying the matching pack and loading its ready workflow... over building a generic graph from scratch.' It also gives exclusions: 'SCOPE LIMIT: this endpoint does NOT include ComfyUI's own core bundled templates...' and 'ALWAYS call this before building OR loading a non-pack/ad-hoc workflow so you can ASK the user before spending paid API credits.' It names alternatives like 'action:"extract_deps" first if you only want to SEE what is missing.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses side effects: overwriting without confirmation, auto-conversion of API format, requirement for a running server and local filesystem access for locks, and read-only behavior for verify_lock. It mentions return values and failure modes, covering behavioral traits comprehensively.
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?
Long but well-structured with bullet points per action. Every sentence contributes useful detail (requirements, side effects, return types). It's verbose due to tool complexity but remains clear and front-loaded with the core purpose.
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 tool with no output schema, it thoroughly describes return values (confirmation message, drift report with empty arrays meaning parity) and prerequisites (running ComfyUI, local FS access). It covers all necessary context for correct invocation without relying on external docs.
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 semantics beyond schema: e.g., explains why Web UI format is preferred, the auto-conversion behavior, and lock file naming convention. This enriches parameter understanding without redundancy.
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 writes to ComfyUI's user library, persists workflows, and captures/verifies provenance locks. It explicitly differentiates from sibling tools: 'This is the only tool here that writes — reading is get_workflow.' Each action (save, lock, verify_lock) is defined with precise verbs and resources.
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?
Provides explicit guidance on when to use each action and contrasts with alternatives. For example, it advises loading existing workflows with get_workflow and modifying them rather than recreating, and pairs lock with verify_lock for drift detection. It also clarifies read-only nature of verify_lock.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses destruction ('DESTROY a whole staged DATASET... Irreversible'), refusal conditions ('Refuses while a running/queued job trains from it'), bounds ('≤ 2MB'), auth needs ('needs a logged-in Claude Code session'), and partial-failure behavior ('Per-file transient failures are reported without stopping the batch').
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 long, but the bullet-per-action structure makes it scannable and each sentence adds new information (prerequisites, return values, safety warnings). It front-loads the core keying concept (name vs id). Slightly verbose, but the length is justified by the eight-action complexity.
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?
With no output schema and no annotations, the description must cover return values, side effects, ordering, and failure modes. It does: datasetPath, per-file warnings, caption returns, irreversibility, and auth failure behavior. The 100% schema coverage and eight-action enumeration leave no obvious gap.
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 the baseline is 3. The description adds cross-parameter semantics: which action requires which params, how ref resolution works ('resolved against the connected ComfyUI's output/input dirs'), and the distinction between update/deleteImages and delete. It does not need to restate the schema but adds orchestration context that the schema alone lacks.
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 opens with 'Stage and curate the training DATASETS a LoRA run consumes — the images and their captions' and explicitly separates this from train_start ('the jobs that train on them live in the separate `train_start` tool and are keyed by `id`'). It enumerates eight distinct actions, making the verb+resource scoping unmistakable and distinguishing it from siblings.
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?
It gives explicit sequencing ('Use after gathering images, before train_start (action:"start")'), alternative tools ('to delete a finished job's record and checkpoints use the separate train_start tool with action:"delete"'), and action-specific pairings ('Pair with action:"detail"'). Also includes practical guidance for when to use prepare (e.g., '10-30 varied images').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 it excels. It explicitly states side-effect-free behavior for `create` ('does not contact ComfyUI and has no side effects'), that `validate` does not execute, that `node_info` requires a reachable ComfyUI instance, and even discloses the staleness caveat with `refresh`. It also warns that `create` may reference models that must exist on the server. This is transparent and comprehensive.
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 long but highly structured and information-dense. It begins with a one-line purpose statement, then uses bullet points for each action, making it easy to scan. Every sentence adds value, such as listing template names, operation types, and clear return-value expectations. There is no redundancy or filler; it is appropriately sized for the tool's complexity.
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?
The description fully covers all four actions, their parameters, and return values. It explains that `create` returns the complete workflow JSON, `modify` returns modified JSON plus new node IDs, `validate` returns errors/warnings, and `node_info` returns structural or verbose definitions. It also notes the acceptable input formats for `validate` (API or saved UI export). Given no output schema, this is complete guidance for an agent to call the tool correctly.
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?
While the schema covers 100% of parameters with detailed descriptions, the description adds meaningful behavioral context beyond the schema. For example, it explains that unsupplied `params` fall back to template defaults and that the result may reference models that must exist on the ComfyUI server. For `node_info` it describes the structural summary vs. verbose output and the 20-node threshold. These extras go beyond the schema's property descriptions, justifying a score above the baseline of 3.
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's purpose: 'Author and check ComfyUI workflow JSON.' It then breaks down each action (`create`, `modify`, `validate`, `node_info`) with specific verbs and resources, making it obvious what each operation does. It also distinguishes itself from siblings by noting that `create` is 'pure local generation' with no ComfyUI contact, which differentiates it from `enqueue_workflow`.
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 routing guidance: it tells the agent to pass the output of `create` to `validate` or `enqueue_workflow`, explaining that `validate` runs without executing, and `node_info` is for inspecting installed node types. It also clarifies when to use `refresh` and `verbose`, giving clear contextual triggers. This is strong usage guidance with direct references to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (openWorldHint, destructiveHint, idempotentHint false) are enriched substantially: the description marks actions 'Read-only', explains the destructive cancel semantics, leftover .partial resumable bytes, remote-vs-local dispatch caveats, stale-heartbeat handling, and the 'silently rejects the download... does not guarantee the file landed' failure modes. No contradiction with annotations.
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?
Well organized by action with a clear required/optional breakdown, but notably verbose with substantial repetition — the remote ComfyUI caveat (network_mode=personal_cloud, 'does not guarantee the file landed') and the stale-heartbeat/duplicate-dispatch warning are restated nearly verbatim across multiple actions. Comprehensive, yet could be tightened.
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?
Given there is no output schema, the description thoroughly explains return values and side effects: status reports download state, destination path, byte progress; search returns ranked lists with modelId, author, downloads, likes; resolve_missing reports size, source, precision and VRAM fit. Error/edge cases (id matching nothing, unknown route, duplicate ids) are all covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema coverage is 100%, the description adds significant meaning beyond the schema: it explains how params flow between actions (e.g., 'Each hit's username feeds action:"search_civitai" {creator:...}'), clarifies when tray_id is needed, interprets limit per action, and gives usage context for base_models, creator (EXACT username), and workflow (API format).
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 states a very specific verb+resource (download models into ComfyUI) and enumerates 8 distinct actions with clear responsibilities. It also distinguishes itself from siblings, e.g. 'For packs of custom nodes (not models) use search_custom_nodes instead'.
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?
Usage guidance is explicit and exhaustive: it specifies when to use each action, which params are required per action, and explicitly points to alternatives ('For CIVITAI searches... use action:"search_civitai" instead'; 'For HuggingFace search use action:"search"'). Flow sequences are spelled out (search_civitai → download_civitai).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully takes on the burden of behavioral disclosure. It covers async behavior ('Returns immediately... does NOT wait for completion'), seed handling ('used EXACTLY as supplied... NOT re-randomized'), SSRF protections ('loopback/private/metadata IPs rejected'), read-only vs. run modes, error responses, and timeout semantics. This is comprehensive transparency beyond what any annotation could succinctly convey.
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?
Though the description is long, it is tightly structured by action with clear headers and uses an introduction sentence that front-loads the primary use. Every sentence either specifies behavior, provides a cross-reference, or clarifies a schema nuance. Given the scale (5 actions, 11 parameters, several security and async details), the length is justified and the structure makes it easily scannable.
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?
Despite lacking an output schema, the description explicitly states return values for each action (e.g., 'prompt_id and queue position', 'new prompt_id and the source prompt_id', 'slots', '{prompt_id}'). It also covers error handling, timeouts, read-only vs. execution modes, and integration with sibling tools, making it highly complete for a complex multi-action tool.
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 schema already describes all 11 parameters with 100% coverage, so the baseline is 3. However, the description adds substantial relationship context: it binds each parameter to specific actions, explains the 'same keys' convention between template_schema and run_template, and clarifies that `disable_random_seed` is a no-op for action:"enqueue" (issue #865). This goes well beyond a mere restatement of schema fields.
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 opens with a clear, specific verb+resource: 'Submit work to the ComfyUI execution queue — the primary way an agent starts a render.' It then enumerates five distinct actions, each with its own purpose, making it unambiguous what the tool does and how it contrasts with the broader toolset. This distinguishes it from sibling tools that handle workflow creation, retrieval, or inspection.
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 is explicit about when to use each action and provides direct alternatives: e.g., 'for a fresh-seed re-run of a past job, use action:"rerun"' and 'To re-run from a registered ASSET instead of history, use generate_image (action:"regenerate").' It also contrasts the full enqueue chain with the one-shot run_template action, offering clear decision guidance. This far exceeds the minimum 'clear context' threshold.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and exceeds it. It discloses read-only status, local vs. remote behavioral inversions, registry expiry/TTL, that list_outputs does not return bytes, that video/audio are saved to disk rather than inline, save_dir path resolution pitfalls (Windows drive-less paths), and preview-size downscaling. These go far beyond what a schema or annotation would capture.
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?
Although long, the description is tightly structured with a leading summary, numbered action bullets, and paragraph breaks for exceptions. Every clause transfers new information; there is no filler, tautology, or repetition of schema mechanics. The length is proportionate to the tool's genuine complexity (seven actions, remote/local differences, multiple parameter combinations).
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?
Given 20 parameters, 7 actions, no output schema, and no annotations, the description leaves little unanswered. It covers return behavior (inline image vs. saved file vs. JSON/markdown), side effects (write-back on convert), failure modes (remote listing can't confirm VHS videos), ordering semantics (newest-first), and integrations with sibling tools (chain with upload_image stage). It is self-sufficient for an agent to invoke correctly.
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% and each parameter has a rich description, so the baseline is 3. The description adds extra value by organizing parameters per action, clarifying the dual meaning of the 'format' enum ('Two unrelated meanings... each action accepts only its own half'), and spelling out required versus optional combinations for each action (e.g., 'convert' requires format plus exactly one of asset_id/path). This is a meaningful layer 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 opens with a specific verb+resource ('Fetch, browse and inspect ComfyUI images and registered assets') and then enumerates seven distinct actions ('get', 'view', 'list_outputs', etc.), each with a clear verb and target. It explicitly differentiates from siblings by naming get_history and upload_image as alternatives. This is a model of purpose clarity.
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 gives explicit when-to-use guidance for each action, including concrete exclusions: 'Use get_history (action:"list") first to obtain the filename', 'USE THIS TO CONFIRM A VIDEO RENDER... when get_history shows the prompt done but lists no output', and remote-vs-local caveats with alternative actions ('Check a specific filename with action:"get" or upload_image instead'). It states when list_outputs should not be used (remote) and how to choose between get and view.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full transparency burden and exceeds it: it declares 'Every action here is READ-ONLY', discloses the list action's careful absence semantics ('It never reports an absence it did not establish... an EMPTY listing says the library could not be CONFIRMED empty'), and explains query's token-bounded output with a tail that names which cap fired. It also reveals redaction behavior ('Secrets and image tensors are redacted') and format defaults, going far beyond what schema fields could convey.
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 long (~700 words) but well-structured with bolded action headers, consistent bullet formatting, and an excellent front-loaded first sentence that establishes scope and sibling differentiation. Some redundancy exists — for example, the analyze-versus-get preference is stated in both the 'get' and 'analyze' bullets, and 'exactly one of path/filename/graph' appears both in the prose and the action parameter description. For an 8-action, 21-parameter tool, the length is largely warranted.
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 must cover return behavior — and it does for every action: list returns a numbered library list, strip returns conversion warnings plus a node-type summary plus the stripped graph, query output is token-bounded with identifiable caps and retry advice, and prompt_director returns sanitized runtime state with redactions. Prerequisites ('Requires a running ComfyUI server'), edge cases (empty listing ambiguity), and cross-tool integration guidance are all addressed. This is complete for the tool's considerable complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds substantial operational meaning: it documents the where-predicate operator syntax ('ops = != >= <= > < ~contains'), explains the two-cap truncation system so agents know to raise max_chars rather than limit, and specifies per-action parameter requirements (slice requires groups; strip/slice/query require exactly one of path/filename/graph). It also clarifies the format union's refusal behavior ('refuses the third rather than guessing at an alias'), which the schema alone does not convey.
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 opening sentence nails the purpose: 'Return, list, summarize or query a SAVED workflow FILE — files on disk, named from the library or given as a path/JSON — NOT the graph open on the user's canvas (that is panel_graph_outline).' It uses specific verbs, names the resource exactly, and explicitly excludes the live canvas while naming the sibling that handles it. Each of the eight action values is further defined with its own precise behavior.
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 is saturated with explicit when/when-not guidance and named alternatives: 'saving and locking are save_workflow', 'Use action:"analyze" instead if you just need to UNDERSTAND the workflow... Use action:"get" only when you need the actual JSON for enqueue_workflow, create_workflow (action:"modify"), or save_workflow', and 'For the LIVE canvas this is panel_query_graph instead.' It also gives pairing advice, such as using slice then strip, and explains why strip can load files that list and panel_open_workflow cannot resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: restart requirements, irreversibility of uninstall, pinning refusals, fallback from comfy-cli to Manager HTTP, post-operation re-reads to catch no-ops, and which operations require a local install. This exceeds typical transparency.
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 long but structured with clear bullets per action and front-loaded with the core purpose. Every sentence carries meaningful info, but the sheer volume could be overwhelming; a slightly more concise wording would earn a 5.
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 complex tool with 9 actions and 8 parameters, the description covers every action, parameter interactions, edge cases, refusals, fallbacks, and post-operation verification. It is complete even without an output schema, as it tells what results disclose fallback behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds significant meaning: id is defined per action (registry id, git URL, or module name; 'all' for update/fix), mode is explained as two distinct groups, ref/version precedence is clarified, and useCmCli fallback behavior is detailed. This adds far 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 opens with a specific verb + resource statement: 'Install, repair, enable/disable and remove ComfyUI custom node packs on this ComfyUI.' It clearly distinguishes from siblings by pointing to search_custom_nodes for finding packs and install_comfyui for panel operations, and the action parameter enumerates all operations.
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?
Explicit guidance is provided: use search_custom_nodes to find packs, prefer action:'disable' over 'uninstall' for reversible cleanup, and route panel targets through install_comfyui(action:'panel'). The description also covers when to use each action and when not (e.g., refusing 'all' while a panel is version-pinned).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden, and it excels: it states read is non-destructive, propose 'does NOT write the file' and 'NEVER write metadata directly,' and fetch_civitai is 'READ-ONLY... WITHOUT writing anything.' It also discloses degradation behavior when the optional node is absent and warns that propose REPLACES the live proposal, requiring full field sets.
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 lengthy but efficiently structured with bullet-pointed actions and bolded key terms. It front-loads the primary purpose and each action gets focused guidance; the density of information justifies the length, though it could be tightened slightly.
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 complex three-action tool with no output schema, the description is remarkably complete: it enumerates the read return fields (classify, model_card, prompt_director, modelspec, ss_tag_frequency, etc.), describes propose behavior (diff-review window, no write), and details fetch_civitai's data and mining advice. Dependencies and failure modes are explicitly covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet the description adds significant meaning beyond schema: it specifies which params are required per action ('BOTH required for read/propose'), provides an example call, explains the `fields` object for propose, and details the `version_id` fallback. It also clarifies that `note` is optional.
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 opens with a specific verb+resource: 'Curate a model file's embedded .safetensors metadata (Model Explorer).' It clearly distinguishes itself from sibling tools by noting 'NOT the separate lora_catalog' and details three distinct actions (read/propose/fetch_civitai), making its scope unambiguous.
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?
It provides explicit when-to-use guidance for each action: 'Call this FIRST...' for read, 'Call whenever you have a proposal...' for propose, and 'Call this when the embedded metadata is thin...' for fetch_civitai. It also names a sibling dependency ('download_model action:'download_civitai' sidecar') and clarifies when not to use it via the lora_catalog exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is exceptionally transparent about side effects: publish is flagged as IRREVERSIBLE and EXTERNAL, write refuses to clobber without overwrite, patch is two-phase with jail-checking, git writes require an environment flag and otherwise return a DISABLED_BY_CONFIG refusal, and verify restarts ComfyUI unless restart:false. It also documents environment dependencies (REGISTRY_ACCESS_TOKEN, COMFYUI_MCP_ALLOW_GIT_WRITES). Since no annotations are provided, the description fully carries the transparency burden and does so comprehensively.
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 extremely long, but the complexity of a 9-action, 27-parameter tool justifies the depth. It is well-structured with bullet-per-action subsections and consistent formatting. Each sentence carries specific information (e.g., tooling details, file lists, environment variables). While it could be tightened, the verbosity is purposeful and not redundant, so it earns a high but not perfect score.
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?
Given the tool's complexity and lack of an output schema, the description is remarkably complete. It explains the full author workflow, return types for each action (e.g., truncated line ranges, match lists with caps), security mechanisms (jail-checking, two-phase git apply), and dependencies. It also covers edge cases (existing directory handling, non-repo packs, case sensitivity). No critical information is missing for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 27 parameters and 100% schema coverage, the description adds substantial meaning beyond the schema's type/nullability. For each parameter it explains context-dependent semantics (e.g., 'path' means pack-relative for read/write/search but an absolute directory for publish; 'name' has different roles across scaffold/verify/publish). It also explains defaults, hard clamps, and precedence (e.g., class_types overrides name). The rich per-parameter explanations fully disambiguate the input 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 clearly and specifically states the tool's purpose: authoring, editing, testing, and publishing ComfyUI custom node packs. It enumerates nine distinct actions with explicit use cases, and the author-loop framing (scaffold → verify → publish) makes the overall intent unambiguous. The verb+resource structure is precise for each action.
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 when-to-use guidance for every action, including the author-loop steps, and explicitly references alternatives such as install_custom_node and bisect. It states conditions for each action (e.g., 'This is the FIRST step of the author loop', 'Use this to orient before action:read/search', 'Requires comfy-cli installed and REGISTRY_ACCESS_TOKEN set'). It also notes when to prefer patch over write. No ambiguity remains about when to invoke this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden; it delivers extensively: cancel waits and verifies, escalates to /free, reports WEDGED; edit/move re-queue under a new prompt_id; cancel_queued verifies removal and reports race conditions. It also discloses read-only actions and side effects in detail, far exceeding what a typical tool description provides.
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 long but matches the natural complexity of an 8-action queue management tool. It is well-structured with clear action headers and front-loaded verbs. Some repetition exists (e.g., 'requires a reachable ComfyUI server'), but overall every major section adds necessary behavioral nuance.
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?
Despite having no output schema, the description explains expected return data for status (booleans, execution stats, text_outputs) and error behaviors for cancel and cancel_queued. It identifies prerequisites, edge cases, side effects, and system interactions (ComfyUI interrupt restrictions) thoroughly for a tool with this many branches.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is already 100%, the description adds crucial semantics beyond the schema: 'include_workflows' can be large, 'clear_pending' is recommended after a stuck render, and 'prompt_id' has different requiredness depending on the action. It clarifies which parameters are optional/required per action, giving the agent actionable usage context not present in the raw 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 opens with a clear verb+resource statement: 'Inspect and manage the ComfyUI execution queue.' It further enumerates eight distinct actions, each with specific behavior, and clearly differentiates queue operations from related sibling tools like enqueue_workflow, get_history, and restart_comfyui.
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 gives explicit when-to-use guidance per action, including recommendations like 'Use this before action:"cancel"...' and fallback alternatives like restart_comfyui for wedged jobs. It also clearly distinguishes cancel vs cancel_queued vs clear, and explains when status is the ONLY way to retrieve certain outputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations (openWorldHint, idempotentHint:false, destructiveHint:true) by disclosing billing states ('create and start BILL; stop ends billing'), the dead-man switch mechanism (auto-stop if heartbeats cease, user API key never leaves machine), that stop keeps the disk and is reversible, and that connect retargets but does not stop the pod. It also notes the ~30-90s boot delay and the need to follow with status/connect, adding rich behavioral context not present in structured data.
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?
Although long, the description is meticulously structured with a leading 'SPENDS MONEY' warning and per-action bullets that are each information-dense but not redundant. Every sentence adds operational value—billing implications, readiness checks, referral economics, dead-man behavior. It is front-loaded with the most critical safety notice and organized for fast scanning, so despite its length it is efficient and well-earned.
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?
This is a complex 8-action, 8-parameter tool with no output schema, yet the description covers all actions, their prerequisites, side effects, required follow-ups, and sibling tool references. It explains return behavior (e.g., status returns desired status, GPU, cost, proxy URL; create tries multiple GPU types) and operational flows (deploy link → create → connect → use_local). The description is self-sufficient for correct tool invocation and session management.
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 the baseline is 3. The description adds practical parameter semantics by mapping each parameter to its applicable action and clarifying side effects (e.g., connect flag is create-time only, deadman default true for stock template, gpu_type fallback list). The schema already documents parameters well, but the description reinforces which combinations matter and what happens at the orchestration level, earning 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 opens with a specific verb+resource combination: 'Deploy, start, stop, inspect and connect to RunPod cloud GPU pods, and switch rendering between your local machine and a pod.' It clearly distinguishes the tool from siblings like runpod_watch by enumerating the exact action-driven operations and noting it is the main pod manager, not a watcher/troubleshooter.
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 when-to-use guidance for every action, including exclusions and alternatives: e.g., 'For onboarding a NEW RunPod user, prefer action:"deploy_link"', 'Call this first to see what state a pod is in before starting/stopping/connecting', and 'If the pod isn't ready it tells you what's missing (run action:"start" / runpod_watch action:"troubleshoot" first).' It also warns about billing and confirmation requirements, giving clear operational guardrails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the safety and behavior burden. It discloses that `watch` arms idle auto-stop and can stop a pod, `unwatch` disables auto-stop, and `troubleshoot` is read-only with a specific checklist. It even notes the ~15s refresh rate, giving the agent a clear picture of side effects and operational behavior.
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 longer than average, but every sentence earns its place by adding safety, usage, or action-specific detail. The structure is clear: a one-sentence purpose, a prominent warning, then bulletized action definitions. It is front-loaded with the most important caveat about not deploying/resuming pods.
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?
Given the multi-action nature, the absence of output schema, and the interaction with sibling tools, this description is remarkably complete. It covers prerequisites (runpod tool for deploy/resume), action-specific behavior, parameter dependencies, and what `troubleshoot` checks and returns.
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 schema already provides 100% parameter coverage and documents the `pod_id` dependency on `action`. The description adds value by giving each `action` enum value a concrete semantic meaning (e.g., watch starts broadcasting, unwatch clears the watched pod), but it does not significantly exceed the schema's structural information.
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 opens with a clear verb+resource statement: 'Watch a RunPod pod's live status in the control panel, stop watching it, or diagnose why it isn't usable.' It distinguishes itself from the sibling `runpod` tool by explicitly stating that it does not deploy or resume pods, so the agent can select this tool without confusion.
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 gives explicit when-to-use guidance for each action: use `watch` to monitor a pod without retargeting comfyui-mcp, use `troubleshoot` when a pod 'won't connect' or ComfyUI is unreachable, and use `runpod action:"stop"` for stopping a pod. It also warns not to watch a deliberately idle pod that must stay up, providing clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: read-only, network-only, HTTP-based, no local ComfyUI dependency, client-side ranking of a fixed window, and automatic fallback to exact registry ID when no keyword match. It also details the two action modes (search vs details) and their respective behaviors, going well beyond a simple 'search' label.
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 substantial but well-organized: front-loaded with the main purpose, followed by key constraints, then a structured breakdown of the two actions. Each sentence serves a purpose, and the action parameter is clearly explained with examples. Despite its length, it avoids redundancy and is easy to scan.
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?
Given no output schema, the description fully explains return values for both actions: search returns a ranked list with specific fields (id, name, author, install count, latest version), and details returns full pack info including node types and changelogs. It also covers prerequisites (network-only, no local ComfyUI) and points to related tools, making it complete for an agent to invoke correctly.
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 schema already covers 100% of parameters with descriptions, so baseline is 3. The description adds semantic value by explaining the action workflow (search first, then pass id to details), the relationship between query and id, and the meaning of pagination defaults. This extra context raises the score above the baseline.
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 action: 'Discover ComfyUI custom node PACKS in the public ComfyUI Registry' with a specific verb and resource. It also distinguishes from siblings by explicitly excluding models (download_model) and local installs (list_local_models), making the tool's scope unmistakable.
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 when-to-use and when-not-to-use guidance: 'Read-only and network-only... does NOT require a running ComfyUI or COMFYUI_PATH'. It names alternatives for models and local installs, and instructs to use install_custom_node for installing or managing packs, offering clear decision paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers: it discloses the HTTP endpoints used, behavior for local and remote ComfyUI, handling of custom input/output directories, return values, and the important fact that only the 'output' action sends bytes off the machine. It also surfaces edge-case behavior like '..' being refused in filename paths.
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 front-loaded summary and action-based bullets, which is appropriate for a complex tool with five modes. However, phrases like 'Works for both local and remote ComfyUI' and 'via the HTTP /upload/image endpoint' are repeated three times each, adding unnecessary redundancy.
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?
Given the tool's high complexity (10 parameters, nested destination objects, multiple action modes) and no output schema, the description is remarkably complete. It covers all actions, parameter interactions, return values, edge cases, and even notes an API compatibility quirk ('async' accepted but uploads complete before returning).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial parameter semantics beyond the schema: it explains the dual meaning of 'filename' across actions, subfolder qualification for loaders, the 'as_filename' override for staging, and the exact relationship between 'action', 'source_path', 'asset_id', and 'destination'. The examples and warnings make parameter behavior significantly clearer.
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 identifies the tool as an upload utility for ComfyUI and cloud storage, using a specific verb ('Put a file') and a concrete resource. It differentiates the five action modes (image/video/audio/stage/output) with enough specificity to distinguish them from each other and from sibling tools like get_image.
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 when-to-use guidance for each action, including the 'stage' action as the correct way to chain multi-stage pipelines. It also gives a clear exclusion: 'Do NOT instead copy the output file or guess a filesystem input/ path' because custom input directories will reject the file. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 exceptionally. It discloses seed randomization behavior, persistence of batch_ids across restarts, the hard cap on timeout_s (600s) ensuring wait can never hang, and that action:"output" is safe before batch completion — all beyond what the schema reveals.
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 long but efficiently structured with a lead sentence and action-by-action bullets. Every sentence earns its place; no filler or repetition. Front-loading with the core purpose makes it scannable despite its length.
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?
This complex multi-action tool (7 params, no output schema) is fully explained. The description specifies return shapes for submit, status, output, and wait, including rollup counts, all_terminal, timed_out, and waited_s. It also covers edge cases like errored jobs and pending/polling behavior, making it self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds rich semantics the schema omits: sweep applies each override set to every node that already has that input, workflows and workflow+sweep are mutually exclusive, and each action's parameter requirements are spelled out (e.g., "wait also takes timeout_s"). This materially improves parameter understanding.
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 opens with a clear verb+resource: "Run MANY ComfyUI workflows under one durable batch_id." It then enumerates four specific actions (submit, status, output, wait) that distinguish it from sibling tools like enqueue_workflow and queue. The reference to reusing the enqueue_workflow path further clarifies its niche.
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?
Directly names when to use this tool and explicitly contrasts with alternatives: "Reuses the enqueue_workflow path", "like create_workflow (action:"modify")", and "Same status source as queue (action:"status")". It also tells users to feed output filenames to get_image, providing cross-tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It does so admirably: repeatedly states read-only guarantees, clarifies that stats/suggest use a LOCAL database not ComfyUI, explains the fallback to most recent failed/successful run, warns about lag after a run finishes, and notes that stats return empty until generations exist. No contradictions with annotations since none exist.
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 long but inherently complex with four actions and six parameters. It front-loads the core purpose in the first sentence, then uses clear bullets and action-specific subsections. Every sentence delivers distinct information: edge cases, fallbacks, data-source distinctions, and cross-tool links. No wasted words or 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?
For a multi-action tool with no output schema and no annotations, this description is exceptionally complete. It covers return values (status, timing, filenames, error tracebacks, missing models, node types, statistics), behavioral nuances (empty stats, lag, fallback logic), and prerequisites (works without ComfyUI for stats/suggest). It also provides actionable next steps for failure diagnosis, making it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already covers 100% of parameters, the description adds substantial semantic value: it maps each parameter to specific actions, explains defaults (limit default 10, prompt_id omission behavior), clarifies that prompt_id behaves differently for list vs diagnose, and gives example values (model_family: 'sdxl', 'flux'). It also explains which parameters interact with which actions, going far beyond the schema's short descriptions.
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 opens with a clear verb+resource statement: "Read what has already been generated on this machine" and then enumerates four specific actions (list, diagnose, stats, suggest) each with a distinct purpose. It clearly differentiates from siblings like get_image and get_workflow by focusing on execution history, failures, and settings usage.
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 when-to-use guidance: 'To diagnose WHY a run FAILED or what is missing, prefer action:"diagnose"', 'Use action:"list" when you need the run's OUTPUTS or timing', and 'Call this whenever a run fails... instead of guessing from raw logs.' It also names alternative tools for follow-up actions (download_model, search_custom_nodes) and contrasts stats vs suggest. This is model-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description continuously discloses behavior beyond the schema: it explicitly states it never installs into the MCP server's Python environment, never overwrites an existing install, runs synchronously (blocking), modifies files on disk among side effects, and thaws the swapfile on macOS. It also specifies requirements for existing files and aftermath. Since no annotations are present, this fully carries the transparency burden.
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?
Although long, the description is extremely well structured: each action is a clearly titled bullet with sub-points, and the parameter descriptions are cross-referenced. It is verbose but necessary given the complexity, and every sentence adds value with no fluff.
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?
The description is remarkably complete: it covers installation location, dependency management (venv isolation), error handling (no overwrites), platform notes (no Windows support, EBUSY), async vs sync behavior, and even specifies when parameters are required or optional per action. It leaves no ambiguity about side effects (e.g., modifies files on disk, reinstalls requirements) or prerequisites (target path must be empty).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning to parameters: for each action it clarifies which parameters apply, e.g., that target_path must be an empty/nonexistent directory, that python_version selects 3.10/3.11/3.12, that use_uv prefers uv over pip, and that venv is always created inside target_path. It explains the behavior of each parameter in context, going well beyond the schema's brief descriptions.
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 explicitly defines the tool's purpose as installing, updating, and configuring a local ComfyUI installation, its sidebar panel, and the MCP server itself)Skip it clearly differentiates from sibling tools (e.g., install_custom_node, download_model) by naming the specific resources and actions. Each action (install, update, update_all, panel, environment, configure_manager) is clearly scoped with specific verbs and targets.
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 when-to-use guidance per action: e.g., action:"install" requires target_path, action:"update" is for local servers only and errors on remote --comfyui-url, action:"configure_manager" requires manager_setting, etc. It also contrasts with sibling tools: 'This updates comfyui-mcp ITSELF — not ComfyUI, not the sidebar panel, and not custom nodes (install_comfyui (action:"update_all")).' This makes the choice among actions and siblings unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so exceptionally. It flags destructive actions loudly ('THIS IS DESTRUCTIVE AND HAS NO UNDO'), discloses read-only vs mutating actions, explains fallback behavior (REST-first then filesystem), path traversal rejection, directory refusal, remote unsupported for remove, and restart requirements. It also covers edge cases like unconfirmed display fallback and sidecar-based CivitAI metadata. No behavioral trait is hidden.
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?
Though long, the description earns its length: it covers six actions with clear bullet-like separators, each with relevant warnings and context. The opening line gives an instant summary, and every subsequent sentence delivers specific, non-redundant information. The structure makes scanning easy despite the complexity.
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?
Given the tool's complexity (6 actions, 8 parameters, no output schema), the description is remarkably complete. It describes return behavior for most actions (grouping by type, fallback size/modified time, embedding names, updated config view, generic categories for list_paths) and explains side effects (restart needed, unlink bypassing recycle bin). No critical aspect—safety, scope, or constraints—is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds substantial semantics beyond the schema. It explains the dual meaning of `path` (model file vs directory per action), how `target` resolves live configs, and that `action` drives the entire behavior. It also describes nuances like path resolution across extra_model_paths.yaml roots and the distinction between deleting a file vs editing YAML, which the schema alone does not convey.
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 opens with a clear, specific statement: 'Inspect what models this ComfyUI has installed, and where it looks for them' — a concrete verb+resource+scope. It then enumerates six distinct actions under the same tool, making it obvious what each invocation does. It also distinguishes itself from the sibling download_model tool by pointing users there for searching and fetching new models, avoiding confusion.
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?
Explicit guidance is provided throughout: 'Use to see which models are already available before generating or downloading; use download_model action:"search" to discover new models on HuggingFace, then action:"download" to fetch them.' The description also warns against confusing remove with remove_path, tells users to confirm the exact path before calling remove, and explains when to use standalone/desktop config targeting. Alternatives and exclusions are clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the read-only nature of list, write behavior for save, the requirement for local install for named saves (unavailable on remote), and that restore applies on next restart. This is thorough and actionable.
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 uses a well-structured bullet format to cover three actions. Each sentence provides essential information, and the length is appropriate for the tool's complexity without redundancy.
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?
Despite lacking output schema and annotations, the description comprehensively covers the tool's operations, constraints, and dependencies (e.g., workspace tool). It leaves little ambiguity about invocation or behavioral expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful semantics beyond the schema: it explains how `action` drives behavior and clarifies `name` optionality/requirement depending on the action, plus remote/local caveats. This goes well beyond the baseline.
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 identifies the tool as managing custom-node snapshots via ComfyUI-Manager and enumerates three specific actions (list/save/restore). This distinguishes it from sibling tools like install_custom_node and node_pack.
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 per-action usage scenarios, including when to omit name for timestamp-named saves, and when a name requires a local install root. It explicitly points to the workspace tool for a prerequisite, giving concrete guidance for when to use each action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: launching docker containers, ssh-driven pod training, long-running behavior with polling, docker stop for cancel, irreversibility of delete, and no-side-effect guarantees for preview_config. It also documents what happens on completion (delivery per deliverTo, cataloging when local) and recovery behavior if cancel fails.
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 long but perfectly structured with a front-loaded summary followed by action-based bullets. Each sentence earns its place, covering all seven actions, required parameters, side effects, and safety warnings. The organization makes the density manageable and scannable.
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?
This is a complex 14-parameter tool with six actions, nested params, and no output schema or annotations. The description addresses all operational aspects: prerequisites, side effects, safety, read-only actions, and next steps after completion. It even covers edge cases like cancel reverting to running and delete requiring cancellation first. The coverage is comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds significant meaning beyond the schema: it specifies which parameters each action requires, clarifies that `name` names the run not the dataset, gives examples for id and trigger, and explains parameter fallback behavior. It also notes that preview_config enforces the same bounds as start, adding practical semantics.
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 opens with a clear, specific statement: 'Run and inspect LoRA training JOBS — launch a run, poll it, stop it, delete it, and read back the settings behind it.' It also explicitly distinguishes from the sibling train_prepare_dataset tool by noting jobs are keyed by `id` while datasets are keyed by `name`. This is a specific verb+resource combination that fully disambiguates the tool.
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 gives explicit usage guidance per action, including when to omit `id` for status, when to use `cancel` vs `delete`, and when to call `list_flows` first. It names alternatives like train_prepare_dataset for dataset deletion and train_doctor for readiness checks, providing clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![comfyui-mcp MCP server](https://glama.ai/mcp/servers/artokun/comfyui-mcp/badges/card.svg)](https://glama.ai/mcp/servers/artokun/comfyui-mcp)

Score Badge

Copy to your README.md:

[![comfyui-mcp MCP server](https://glama.ai/mcp/servers/artokun/comfyui-mcp/badges/score.svg)](https://glama.ai/mcp/servers/artokun/comfyui-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/artokun/comfyui-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server