ComfyUI MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a unique resource and action, from health checks to node introspection, workflow editing, execution, and queue control. Even closely related tools like add_node and set_input have clear boundaries, leaving no ambiguity.
Naming Consistency5/5
All tools follow a consistent comfyui_verb_noun snake_case pattern. Verbs like list, get, create, add, remove, connect, disconnect, and validate are consistently used, making the toolset predictable and easy to navigate.
Tool Count4/5
At 23 tools, this is on the heavy side, but the breadth is justified by the complex domain of ComfyUI workflow management. Each tool serves a distinct purpose, and the count remains reasonable given the need to cover discovery, editing, validation, execution, and file I/O.
Completeness4/5
The toolset covers the full lifecycle of workflow management, including creation, importing, editing, validation, running, queue inspection, and output retrieval. Minor gaps exist, such as the lack of a delete_workflow tool or a list_runs tool, but these are not critical for core usage.
Average 3.5/5 across 23 of 23 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must disclose behavioral details, but it only states the core action. There is no mention of side effects (e.g., file overwriting, directory creation), permission requirements, or what the tool returns after downloading.
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 a single, focused sentence with no wasted words. It front-loads the action and destination, making it easy to scan, though the extreme brevity limits the information it can convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, an output schema, and no annotations, so the description needs to provide substantial context. It only covers the high-level action, leaving parameter semantics, behavioral expectations, and usage context entirely unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any of the four parameters (filename, prompt_id, subfolder, output_type). The agent gets no additional meaning beyond the raw parameter names and defaults, which is insufficient for a tool with an optional prompt_id and multiple output options.
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 specifies the action ('Download') and the resource/destination ('generated ComfyUI file into this server's managed output directory'). It distinguishes the general direction from sibling tools like comfyui_upload_image, though it does not explicitly compare itself to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus related tools such as comfyui_get_run or comfyui_upload_image. It lacks prerequisites, typical use cases, or any caveats about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention whether this operation modifies the canvas, whether it requires the optional bridge to be installed, whether it overwrites existing content, or if any permissions are needed. The phrase 'via the optional bridge' hints at a dependency but doesn't explain failure modes.
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 a single sentence with no wasted words. It is front-loaded with the primary action and object. It is appropriately concise for a simple statement of purpose, though it sacrifices important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and 2 parameters, but the description lacks essential context about parameter meaning, operation details, and relationship to sibling tools. It does not explain return values or behavior on error. The output schema reduces the need for return format details, but the overall description is incomplete for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not mention the 'name' or 'mode' parameters at all. Even the schema lacks descriptions. An agent cannot infer what 'name' refers to (workflow name? canvas name?) or what 'mode' with default 'replace' does. This is a severe gap.
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 action ('Render'), the resource ('a managed API workflow'), and the target ('an open ComfyUI canvas'), which distinguishes it from sibling tools like comfyui_run_workflow or comfyui_import_workflow. However, it does not explicitly name alternatives or differentiate itself further, so it's strong but not perfect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only states what it does, with no mention of prerequisites, exclusions, or related tools. For example, it doesn't say 'Use this after creating a workflow' or 'Use comfyui_run_workflow to execute instead'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose what happens if a workflow with the same name exists, whether the 'overwrite' parameter is needed to replace, or any side effects. The 'empty' and 'managed API-format' qualifiers add some context, but crucial behavioral details are missing.
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 a single concise sentence, front-loaded with the action and object. It wastes no words. However, it is overly terse, but conciseness itself is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 3 parameters and an output schema, the description is incomplete. It does not explain parameter semantics, overwrite behavior, or usage context. The presence of an output schema reduces the need to describe return values, but other important aspects remain unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 'name', 'overwrite', or 'description' parameters. The schema only gives types and defaults, so the agent must guess their meaning. The description fails to compensate.
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 creates a workflow, with specific qualifiers 'empty' and 'managed API-format,' distinguishing it from import_workflow or get_workflow. The verb 'create' and resource 'workflow' are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like import_workflow, list_workflows, or get_workflow. The description does not mention any context or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It adds only a hint that verification is optional, but fails to state that this is a write operation that modifies the workflow, or how expected_revision and verify_node_type affect behavior. This is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and adds a secondary optional behavior. No redundant information or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotation coverage, and only a minimal description, the tool lacks sufficient context for an agent to understand workflow modification semantics, return values, or the meaning of 'managed workflow.' The output schema exists but does not compensate for missing operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of parameters such as class_type, inputs, node_id, or expected_revision. The agent receives no help understanding how to populate these fields, making the tool difficult to use correctly.
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 function: adding a node to a managed workflow, with an optional live verification against ComfyUI. This distinguishes it from sibling tools like remove_node and connect_nodes by focusing on the creation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The phrase 'optionally checking it against the live ComfyUI' hints at a validation use case, but there is no mention of when to skip verification or scenarios where other tools (e.g., set_input) would be more appropriate.
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 must carry the full burden. The description communicates that this is a read-only operation returning status and outputs, and enumerates possible statuses. However, it does not disclose return format (though output schema exists), auth requirements, or behavior on invalid prompt_ids, leaving some gaps.
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 a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's core function.
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?
For a simple get with one parameter and an output schema, the description covers the basic purpose. However, it lacks usage context, parameter guidance, and behavioral details that would make it fully self-sufficient, so it's adequate but not complete.
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?
The input schema has one parameter (prompt_id) with 0% description coverage. The description does not explain what prompt_id is or how to obtain it, so the agent must rely on the parameter name alone. This does not compensate for the schema gap.
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 a specific verb ('Get') and resource (a run's pending/running/completed/failed/unknown status and outputs). It is distinct from siblings like comfyui_get_queue or comfyui_run_workflow, though it doesn't explicitly call out the differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It only states what it does, leaving the agent to infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must communicate behavior. It mentions 'allowed' (suggesting restrictions) but does not explain what happens with disallowed files, overwrite semantics, or side effects. The tool's mutation behavior (uploading a file) is clear but lacks detail.
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 a single, front-loaded sentence with no filler. Every word contributes to the core purpose, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no schema descriptions, and no annotations, the description is too sparse. It fails to explain how to specify file paths, what 'allowed' means, or how overwrite and subfolder interact. The existence of an output schema does not compensate for missing parameter and behavioral detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters. file_path, overwrite, and subfolder semantics are left entirely to inference from names, which is insufficient for an agent to invoke correctly.
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 (upload), the object (local image), and the destination/purpose (ComfyUI for LoadImage-style nodes). This distinguishes it from sibling tools like comfyui_list_models or comfyui_run_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for LoadImage-style nodes' implies when to use this tool, but it does not explicitly state when not to use it or provide alternative tools. No prerequisites or workflow context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It mentions that schema/input validation is conditional ('by default'), but does not explain what happens on invalid graphs, whether any side effects occur, or whether the tool is read-only. Safety profile is absent.
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 a single, focused sentence that conveys the core functionality without fluff. It is efficiently front-loaded with the primary action and scope.
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?
The tool has an output schema (so return values are covered) and is relatively simple, but the description lacks usage guidance and parameter semantics. It is minimally viable for a validation tool but leaves gaps that could confuse an agent on when and how to invoke it.
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 description coverage is 0%, so the description must explain the parameters. Only 'live' is indirectly described via 'by default', while 'name' is entirely unexplained. The description does not compensate for the lack of 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 description clearly states a specific verb ('Validate') and resource (graph structure, node schemas, required inputs), distinguishing it from sibling tools like comfyui_health or comfyui_list_workflows. The phrase 'by default' adds nuance about an optional mode, making the core purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description implies validation before running a workflow but does not explicitly state this context or mention sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core connect action and does not reveal what happens if the target input already has a connection, whether the revision parameter is enforced, or what validation is performed. This leaves significant behavioral ambiguity 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is instantly scannable and front-loads the primary action. Every word contributes to meaning, with no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters and no annotations, the description is too sparse to be fully actionable. It fails to mention important behavioral details such as whether existing connections are overwritten, how expected_revision affects execution, or potential failure modes. The output schema exists but does not substitute for missing usage context.
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 description coverage is 0%, so the description must compensate for undefined parameters. It clarifies that source_output is an index and target_input is named, but it leaves workflow_name, expected_revision, and the exact meaning of source_node/target_node unexplained. The description adds minimal value beyond the parameter names themselves.
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 uses a specific action verb ('connect') and identifies the precise resource ('one node output index to a named input on another node'). This clearly distinguishes it from siblings like comfyui_disconnect_input, which performs the opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for wiring nodes together, but it does not explicitly state when to use this tool versus alternatives like set_input or disconnect_input. It lacks a when/when-not comparison, instead relying on the tool name and context to convey its role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states the core action but omits side effects, error behavior, idempotency, or interaction with the expected_revision parameter. For instance, it doesn't say whether disconnecting a non-existent connection raises an error or is a no-op, nor does it explain how the operation affects workflow revision checks.
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 a single, focused sentence with no redundant words. It conveys the essential action efficiently, achieving maximum conciseness without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema (so return values need not be explained), the tool has a concurrency-control parameter (expected_revision) and lacks any behavioral details beyond the basic action. The description is too thin for a tool interacting with a workflow graph, especially given potential error cases and revision handling. Complete for a trivial operation, but this operation has more nuance that warrants elaboration.
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 description coverage is 0%, so the description must compensate by explaining parameters, but it only mentions 'input' generically. The parameter names (workflow_name, target_node, target_input, expected_revision) are self-explanatory to some degree, but the description adds no additional meaning, such as what 'expected_revision' controls (optimistic concurrency) or how 'target_input' should be formatted. This is a significant gap given four parameters total.
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 uses a specific verb ('Remove') and resource ('node connection assigned to an input'), clearly distinguishing it from sibling tools like connect_nodes (which creates connections) and set_input (which sets values). The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (disconnecting an input) but does not explicitly state when to prefer it over alternatives or mention any prerequisites or exclusions. For example, it doesn't clarify what happens if the input has no connection, or that connect_nodes is the inverse operation. The sibling context provides some implicit guidance, but the description itself offers no direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only discloses that overrides are non-persistent, but does not mention side effects such as queueing, asynchronous execution, validation behavior, or potential resource consumption. This is a significant gap for a compute-execution tool, so a score of 2.
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 a single, front-loaded sentence with no filler. It is concise and to the point, earning a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too sparse for a 5-parameter, no-annotation execution tool. It lacks context on execution flow, parameter purpose, and when to invoke it relative to sibling tools. A score of 2.
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 description coverage is 0%, so the description must explain parameters. It only touches 'overrides' (non-persistent), and does not clarify 'name', 'front', 'validate', or 'client_id'. This leaves most parameters ambiguous, so a 2.
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 uses the specific verb 'Submit' with the resource 'managed workflow to ComfyUI', clearly indicating this tool launches a workflow execution. It also mentions optional overrides, which differentiates it from editing or validation tools among 23 siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit alternatives or when-not-to-use instructions, though 'managed workflow' implies a prerequisite of an already-saved workflow. The usage is mostly inferred from the tool name and sibling context, so it earns a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states that the object is imported into a store; it does not mention overwrite behavior, validation, execution semantics, or any side effects. For a mutation tool this is insufficient.
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 one sentence, front-loaded with the verb, and contains no filler. Every phrase contributes to identifying the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema being present and the workflow object being nested, the one-sentence description is too thin for a 4-parameter import tool with no annotations. It leaves out usage context, overwrite behavior, and validation implications, forcing the agent to infer too much.
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?
With schema description coverage at 0%, the description must compensate. It usefully clarifies that 'workflow' is a ComfyUI API-format object, which is not evident from the schema. However, it adds no meaning for name, overwrite, or description, though those are less ambiguous.
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 uses the specific verb 'Import' and identifies the exact resource ('ComfyUI API-format workflow object') and destination ('managed workflow store'). The API-format qualifier distinguishes this from sibling tools like create_workflow or run_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as create_workflow. The phrase 'API-format workflow object' implies use for importing existing API JSON, but there is no direct statement of when not to use it or which sibling to prefer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure, but it only states the basic action. It does not mention that the tool modifies a workflow, how expected_revision affects concurrency, whether validation occurs, or any side effects. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the action and resource, followed by concrete examples. Every part adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, an output schema, and is a mutation tool with no annotations, but the description gives no contextual details about modifying workflows, optimistic locking via expected_revision, or relationships to other editing tools. The output schema reduces the need to describe return values, but the missing behavioral and usage context makes the description incomplete.
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 schema has 0% description coverage, so the description must compensate. It adds useful context for the 'value' parameter by listing example literal inputs, but it does not explain workflow_name, node_id, input_name, or especially expected_revision. The parameter names are self-explanatory, but the description only partially compensates for the missing 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 description uses a specific verb ('Set') and resource ('literal node input') with clear examples (prompt text, seed, dimensions, model name), and distinguishes itself from sibling tools like comfyui_connect_nodes by emphasizing 'literal'. It clearly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'literal node input' implies the tool is for setting direct parameter values rather than connections, and the examples suggest common use cases. However, there is no explicit when-to-use guidance or mention of alternatives like comfyui_connect_nodes, so the guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. While 'Remove pending workflows' states the basic action, it does not mention that the operation is destructive and irreversible, nor that it only affects pending workflows and not the currently running one. This lack of safety-related context is a notable gap for a clear-queue operation.
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 a single, front-loaded sentence with no redundant words. It communicates the essential action directly and efficiently.
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 zero-parameter tool with an output schema, the description covers the core behavior adequately. It could add a note about the complete/irreversible nature, but 'pending' already implies non-running workflows, so the context is mostly 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 tool has zero parameters, so there is no semantic burden on the description. The schema coverage is effectively 100%, and the baseline for 0 parameters is 4, which is appropriate here since no parameter explanation is needed.
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 verb 'Remove' and the resource 'pending workflows from the ComfyUI queue', which precisely conveys the tool's action. It also distinguishes itself from sibling tools like comfyui_interrupt by specifying 'pending' workflows rather than running ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as comfyui_get_queue (to view the queue) or comfyui_interrupt (to stop running workflows). The usage context is only implied by the tool name and description, with no explicit exclusions or prerequisites.
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?
With no annotations, the description carries the transparency burden. It discloses that the tool searches and avoids returning the full large schema, implying a read-only, abbreviated response. However, it does not clarify search semantics (e.g., case sensitivity, partial matching) or pagination limits beyond the parameter default.
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?
A single sentence with no fluff, front-loading the verb and resource, and ending with a meaningful constraint. Every word earns its place.
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?
The tool is a simple search/list operation and an output schema exists, so return values are covered. Still, the absence of parameter explanations and usage exclusions leaves the agent with gaps in how to effectively call the tool, especially with optional category and query.
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 description coverage is 0%, yet the description names no parameters or their behavior. The three parameters (limit, query, category) rely entirely on their names for meaning, which is insufficient for ambiguous ones like category (does it filter core vs custom? node category?). The description should have compensated but does not.
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 uses a specific verb ('Search') and resource ('installed core and custom node types'). It also distinguishes itself from sibling get_node_type by noting it avoids returning the full large schema, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The implied use case is searching node types when the full schema is not needed, but no explicit when/when-not guidance or alternative tools (e.g., get_node_type) are mentioned. This leaves the agent to infer selection criteria.
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?
With no annotations provided, the description carries the full burden. It discloses one key behavior: force=true disconnects inputs that reference the node. However, it leaves other important behaviors unclear, such as what happens without force if inputs reference the node, whether the operation is reversible, or any side effects on the workflow. The disclosed behavior is useful but incomplete.
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 a single, efficient sentence that front-loads the core action and then adds a key conditional behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters, no annotations, and an output schema, the description is too sparse. It does not explain expected_revision, the consequences of force=false when inputs reference the node, or the return value/effect on the workflow. Given the complexity of the parameters and the ambiguous force behavior, this is inadequate.
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 0%, so the description must compensate. It explains the force parameter (true disconnects inputs), and workflow_name and node_id are self-evident from the context. However, expected_revision is entirely unaddressed, and the behavior of force=false when inputs reference the node is not clarified. It adds partial meaning beyond names.
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: 'Remove a node.' It distinguishes itself from sibling tools because no other sibling removes nodes (siblings include add, set, connect, disconnect, etc.). The added detail about force=true further clarifies the scope of 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: remove a node from a workflow, optionally with force to disconnect inputs. However, it does not explicitly state when to use force vs. when not, nor does it mention alternatives like disconnect_input or when to call remove vs. those. The usage context is implied rather than explicitly guided.
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. 'Get' implies a read operation, and the description lists what is returned (inputs, outputs, options, metadata), providing some transparency. However, it does not explicitly state that the operation is safe, read-only, or describe potential errors or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. No wasted words; it is easily scannable and effective.
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 simplicity (one parameter) and the presence of an output schema (so return values are documented elsewhere), the description provides adequate context. It clearly states what the tool returns, though it could have added a note about how to discover valid class_type values via 'list_node_types'.
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?
The schema has one parameter 'class_type' with no description, and the description does not explain its format, valid values, or how to obtain them. It only repeats 'one node class,' which adds minimal meaning beyond the parameter name. With 0% schema coverage, more compensation was needed.
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 gets 'authoritative inputs, outputs, options, and metadata for one node class.' It uses a specific verb ('get') and resource ('node class'), distinguishing it from sibling 'list_node_types' which lists all node types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving details of a specific node type, but it does not explicitly say when to use this tool versus alternatives like 'list_node_types' or how to obtain a valid class_type. The 'one node class' phrasing hints at scope, but explicit guidance is absent.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal one key behavior: 'full workflow payloads are hidden by default', which informs users of the default response content and implies the include_workflows parameter effect. However, it does not explicitly confirm read-only status, rate limits, or other potential side effects, though 'inspect' suggests a safe operation.
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 a single sentence of 12 words, front-loading the core purpose and immediately adding a behavioral caveat. Every word contributes value, with no repetition of the tool name or schema details. This is exemplary conciseness.
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 tool with one optional parameter and an existing output schema, the description is largely complete. It states the scope (running and pending jobs) and the default workflow visibility, which are the most important user-facing aspects. However, it could have briefly mentioned how to include workflows or distinguished between running and pending states, but the output schema likely covers return details.
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 0%, so the description must compensate. It directly explains the core parameter behavior by stating that full workflow payloads are hidden by default, which clarifies the effect of include_workflows=true. This adds meaningful context beyond the schema's default value and title.
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 uses the specific verb 'Inspect' with the clear resource 'running and pending jobs', which precisely identifies the queue inspection functionality. It also distinguishes itself from sibling tools like comfyui_get_run (specific run) and comfyui_clear_queue (clearing) by focusing on the queue state. The extra note about hidden workflow payloads adds useful scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit guidance on when to use this tool versus alternatives such as comfyui_get_run or comfyui_health. There is no mention of preferred contexts, prerequisites, or exclusions. Usage is only implied by the name and the action 'inspect'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the tool's name/action without explaining side effects, idempotency, what happens to queued workflows, or whether it is a no-op when nothing is running.
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 a single, front-loaded sentence with no wasted words. It states exactly what the tool does without extraneous detail.
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?
This is a simple zero-argument action tool, and the description sufficiently identifies the target and action. The output schema exists, so return values need not be explained. However, a brief note on side effects or relation to the queue would make it more robust.
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 tool has zero parameters, so the parameter semantics baseline is 4. No parameter descriptions are needed, and the empty schema is consistent with the tool's purpose.
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 uses a specific verb ('Interrupt') and a specific resource ('the workflow currently executing in ComfyUI'), which clearly distinguishes this from sibling tools like comfyui_clear_queue (queue-level) and comfyui_run_workflow (starting execution).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'currently executing' implies this tool should be used when a workflow is running, providing some usage context. However, it does not explicitly mention alternatives, exclusions, or when not to use it, such as for clearing the entire queue.
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?
With no annotations, the description carries the full burden. It discloses the read-only nature through the verb 'list' and mentions the included data (revision and node counts), but does not discuss pagination, error conditions, or other behavioral traits. It adds some value but lacks richer context.
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 a single, focused sentence with no filler. It efficiently conveys action, scope, and output highlights.
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 zero-parameter, straightforward list operation with an output schema, the description covers the essentials. It could include usage guidance, but the simplicity of the tool lowers the bar for completeness.
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 tool has zero parameters and an empty schema, so the baseline is 4. The description does not need to add parameter detail, and its mention of returned fields is a bonus, though not directly parameter-related.
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 'List' and the resource 'workflows managed by this MCP server,' and adds specific output details (revision and node counts). This distinguishes it from sibling tools like comfyui_list_models or comfyui_get_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: it lists all workflows, so it would be used when an overview is needed. However, there is no explicit statement of when to use it versus alternatives, nor any exclusions or alternative tool mentions, so it does not meet the 'explicit guidance' bar.
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 must carry the full burden. It discloses the two checks performed but does not mention whether it is read-only, what happens on failure, or the return format. For a simple health check this is acceptable but not exhaustive.
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 a single, front-loaded sentence that directly states what the tool does. There is no redundant wording, and every word contributes meaning.
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 simplicity (zero parameters) and the presence of an output schema (which defines return values), the description is complete. It fully covers what is needed: connectivity and canvas bridge status. No additional context is required for an AI agent to invoke it 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 has zero parameters, so the description does not need to elaborate on parameter semantics. By default, a no-parameter tool gets a baseline 4, and the description appropriately does not add unnecessary parameter details.
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 uses a specific verb 'Check' and identifies two clear resources: ComfyUI connectivity and the optional canvas bridge installation. This clearly distinguishes it from sibling tools like comfyui_list_node_types or comfyui_run_workflow, which focus on specific operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description makes it obvious that this tool is for verifying connectivity, it does not explicitly state when to use it relative to alternatives or provide any exclusion criteria. The usage context is implied rather than spelled out, so it meets the minimum viable threshold.
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?
With no annotations, the description carries the full burden. 'List' implies a read-only operation, and the mention of 'installed ComfyUI node packages' adds context about the data source. However, it does not explicitly state safety/read-only behavior, side effects, or performance characteristics beyond the minimal verb.
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 a single, focused sentence with no redundant words. Every word contributes meaning, making it concise and 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?
This is a very simple list tool with no parameters and an existing output schema. The description conveys the core concept and source accurately. Since output schema handles return structure, no further detail is needed for completeness.
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 tool has zero parameters and the schema is empty, so the baseline is 4. The description adds no parameter information because none exist, which is appropriate. No gaps to compensate for.
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 uses the verb 'List' with a specific resource ('workflow templates') and a precise scope ('exposed by installed ComfyUI node packages'). This distinguishes it from sibling tools like comfyui_list_workflows (user workflows) and comfyui_list_node_types (node types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering templates from installed packages but does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool names are mentioned, though the context gives some guidance.
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 accurately indicates a read operation and reveals a behavioral nuance (the include_graph flag affects output compactness), but does not mention permissions, error behavior, or any side effects. For a read tool this is decent but incomplete.
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 short sentences, front-loaded with the purpose, and the second sentence adds actionable parameter guidance. Every word earns its place with no redundancy.
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?
With only 2 simple parameters and an output schema present, the description covers the essentials. It could potentially clarify what 'managed workflow' means or note the default behavior of include_graph (already in schema), but overall it is complete enough for a straightforward getter 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?
Schema description coverage is 0%, so the description must add meaning. It explains include_graph ('false for a compact summary'), which is helpful. The 'name' parameter is not explicitly described, but 'Read a managed workflow' implies the name identifies which workflow. The description compensates reasonably for the schema's lack of 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 uses a specific verb 'Read' with a clear resource 'managed workflow', distinguishing it from siblings like list_workflows (which lists all) or create/update tools. This immediately conveys the tool's core function of retrieving a single workflow.
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 a concrete usage hint ('Set include_graph=false for a compact summary') which guides parameter choice. However, it does not explicitly contrast with alternatives (e.g., when to use list_workflows instead) or mention exclusions, though the purpose is largely self-evident given the tool name.
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?
With no annotations, the description carries the full burden but it only discloses the dual-mode behavior (folders vs models in a folder). It does not mention read-only status, error handling, or sorting, although 'List' implies a read operation and the output schema can cover return format. This is adequate but not rich.
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?
A single, front-loaded sentence with zero unnecessary words. It efficiently conveys the tool's scope and the optional behavior without redundancy.
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 simplicity (one optional parameter) and that an output schema exists, the description covers the primary behaviors. It lacks explicit parameter-to-mode mapping (e.g., 'omit to list folders') but this is easily inferred. Edge cases are not discussed, but overall it is sufficient for basic 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 0%, so the description must compensate. It does by explaining that the optional 'folder' parameter selects between listing folders (omitted) or models within a specific folder, and gives concrete examples ('checkpoints', 'loras'). This adds meaning beyond the bare 'folder' property name.
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 uses a specific verb ('List') and clearly identifies the resource ('ComfyUI model folders' or 'models within one folder'). It provides examples ('such as checkpoints or loras') and distinguishes itself from sibling list tools (node types, templates, workflows).
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: it can list top-level folders or models inside a named folder, with examples of valid folder values. It does not explicitly state when not to use it or mention alternatives, but the purpose is unambiguous enough for an agent to select it appropriately among siblings.
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/yutianxiao6/comfyui-mcp/badges/card.svg)](https://glama.ai/mcp/servers/yutianxiao6/comfyui-mcp)

Score Badge

Copy to your README.md:

[![comfyui-mcp MCP server](https://glama.ai/mcp/servers/yutianxiao6/comfyui-mcp/badges/score.svg)](https://glama.ai/mcp/servers/yutianxiao6/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/yutianxiao6/comfyui-mcp'

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