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 distinct operation—downloading, listing, viewing, writing, queuing, or managing—with no two tools sharing the same purpose. The few related tools (queue_workflow vs queue_batch, list_outputs vs view_latest) are clearly differentiated by their descriptions and use cases.
Naming Consistency4/5
Tool names follow a consistent snake_case verb_noun pattern (list_workflows, read_workflow, write_workflow, queue_workflow, cancel_queue). Minor deviations like 'system_stats' (no verb) and 'pick_top' (verb+adverb) are still clear and do not disrupt readability.
Tool Count4/5
At 16 tools, the set is slightly above the ideal 3-15 range, but every tool serves a distinct purpose in managing ComfyUI workflows, models, outputs, and queue operations. The count feels appropriate for the server's full-featured scope rather than bloated.
Completeness4/5
The domain covers workflow CRUD (list/read/write), model download/list, output retrieval/curation, and queue management with wait/cancel, covering the core lifecycle. Notable omissions are delete operations for workflows and models, which are minor gaps that agents can work around.
Average 3.9/5 across 16 of 16 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits 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 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.
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?
Without annotations, the description must disclose behavioral traits on its own. It only repeats the purpose ('get... state') and does not explicitly state that it is read-only, whether it has side effects, or any other behavioral details. This is a minimal disclosure for a tool with no annotation coverage.
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 efficiently conveys the core purpose. There is no wasted text or redundancy, making it highly concise and well-structured for an agent to parse quickly.
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 the lack of output schema, annotations, and the presence of several related sibling tools, the description is incomplete. It does not explain what the 'queue state' includes, what the return format is, or how this tool fits into a workflow (e.g., polling for task completion). The optional 'prompt_id' parameter's future-only nature is also not addressed.
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 for the single optional parameter 'prompt_id', describing it as 'for future per-job progress'. The tool description adds no additional meaning beyond that, so the baseline of 3 is appropriate when the schema already documents the parameters.
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 function: 'Get current ComfyUI queue state.' It uses a specific verb ('get') and resource ('current ComfyUI queue state'), which distinguishes it from sibling tools like queue_workflow or cancel_queue. However, it doesn't explicitly mention that it's for reading progress, but the meaning is implied.
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 such as wait_for_image or cancel_queue. The description simply states what it does without any contextual cues, prerequisites, or exclusions.
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 folder creation, default sync behavior via scp, and optional NOTES.md. However, it omits important behaviors like whether source files are moved/copied, overwrite semantics, what happens if sync fails, or any permission requirements.
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 sentences, front-loaded with the core purpose, and contains no redundant information. It is efficient and well-structured.
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 tool with 5 parameters and no output schema, the description covers the primary flow but lacks details on return values, error handling (e.g., missing filenames), and edge cases like simultaneous use of local_dir and sync_to_mac. The overall context is adequate but not fully 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?
Schema description coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema, only reinforcing the default sync destination and notes file. It does not clarify parameter interdependencies like local_dir vs sync_to_mac or folder_name constraints beyond what schema already states.
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: curate selected ComfyUI output images into a named folder on spark and sync to the Mac by default, with optional NOTES.md. It distinguishes from siblings like view_image and list_outputs by focusing on copying/curating rather than viewing/listing, though it does not explicitly name alternatives.
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?
Usage context is implied: use this tool to select and save output images to a folder. However, there is no explicit statement of when to use it over siblings or when not to use it, and no exclusions or alternative tool references.
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 disclosing behavioral traits. It only states 'Interrupt the currently running ComfyUI job' without any details on side effects, behavior when no job is running, reversibility, or permissions needed. Given this is a mutation-type operation, the lack of disclosure is a significant gap.
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 with no padding or redundancy. It is appropriately structured for a simple tool, though it could be slightly more informative without losing conciseness.
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 tool has no parameters and no output schema, the description is minimally adequate but omits edge-case behavior (e.g., what happens if no job is running) and any impact on unrelated queued jobs. More context would improve completeness, but the core action is clearly stated.
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 baseline score of 4 applies. The description does not need to explain parameter semantics because there are none to describe.
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 'Interrupt' and clearly identifies the resource as 'the currently running ComfyUI job.' This unambiguously distinguishes it from sibling tools like queue_workflow, queue_batch, and get_progress, making its 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 description states what the tool does but provides no explicit guidance on when to use it or when to prefer an alternative. The usage is implied by the action, but no alternatives or exclusions are mentioned, leaving the agent to infer context.
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 for behavioral disclosure. It only states the action and return format, but does not disclose potential side effects, limitations (e.g., what happens if no outputs exist), or whether it performs any non-obvious operations. This is a gap for a fetch 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, concise sentence that effectively communicates the tool's purpose without unnecessary words. It earns its place completely.
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 parameter and no output schema, the description is largely complete. It specifies the source (ComfyUI output images), the count (last N), and the return type (image blocks). However, it could benefit from mentioning edge cases or failure behavior, but given the low complexity, this is sufficient.
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 fully documents the parameter 'n' with its default value, and the description adds no additional semantic value beyond what the schema already provides. Baseline 3 is appropriate since schema coverage is 100%.
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 'Fetch' and the resource 'last N ComfyUI output images', and specifies the return as image blocks. It distinguishes itself from siblings like view_image (specific image) and list_outputs (listing without fetching content).
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 recent output images, but provides no explicit guidance on when to use this tool versus alternatives like view_image or list_outputs. No when-not-to-use scenarios or alternative suggestions are given.
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 the download mechanism ('via aria2c'), source types, and destination directory, adding useful context. However, it omits behavioral details such as overwrite behavior, whether the download is synchronous, error handling, or whether the output filename is derived from the URL vs the filename parameter.
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 efficiently conveys the purpose, source, mechanism, and destination. There is no redundancy or unnecessary detail, making it well-structured and easy to parse.
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 description provides essential context for a download tool, but lacks information about important behavioral aspects such as whether existing files are overwritten, whether the destination directory must pre-exist, and what the tool returns upon success or failure. Given the lack of an output schema and annotations, a more complete description would improve usability.
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 the schema already describes each parameter (url, kind, filename) clearly. The description does not add additional meaning beyond the schema, such as explaining the enum values or how the filename override interacts with URL-derived naming. Baseline 3 is appropriate because the schema handles parameter semantics adequately.
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 ('Download') and clearly identifies the resource ('a model file') and the action's scope (from Civitai / HuggingFace / direct URL). It distinguishes itself from sibling tools like list_models by focusing on the download action rather than listing.
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 the tool is used to download model files into a chosen directory, but it does not explicitly state when to use it versus alternatives or mention any exclusion criteria. There is no guidance on scenarios where a different tool (e.g., list_models) 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 carries the burden. It discloses that the tool reads a file 'as raw text' and specifies the source 'from spark', but does not mention potential errors, permissions, or side effects. The read-only nature is implied by the verb 'Read'.
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, clear sentence that directly states the tool's purpose, output format, and source. 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?
For a simple one-parameter tool with no output schema, the description adequately covers the core function and return format. It could be slightly richer by mentioning file-not-found behavior, but overall it 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?
Schema description coverage is 100% with the 'name' parameter described as a filename with an example. The description adds only 'from spark' context, which is marginal. Baseline of 3 is appropriate since the schema already handles parameter meaning.
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 specific action (read) and resource (workflow JSON file from spark), and distinguishes it from siblings like write_workflow and queue_workflow by emphasizing 'Read' and 'raw text'.
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 does not explicitly state when to use this tool versus alternatives. Usage is implied by the name and sibling contrast, but no direct guidance or exclusions are given.
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 full burden. It discloses the core behavior (polling and returning the image) but does not mention timeout behavior, failure handling, or return format. Given the simplicity of the tool, this is adequate but not fully transparent.
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 immediately conveys the tool's purpose, condition, and output. No unnecessary words or repetition.
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 polling tool with a well-documented schema, the description covers the essential context (what it does, when triggered, what it returns). It lacks explicit error/timeout behavior, but given the low complexity and absence of an output schema, the description 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?
Schema coverage is 100% with descriptions for both prompt_id (from queue_workflow result) and timeout_sec (default 120). The description adds no extra meaning beyond the schema's parameter documentation, so it meets the baseline for high schema coverage.
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 specific action ('Poll ComfyUI'), the condition ('until the given prompt_id finishes'), and the result ('return the generated image'). This distinguishes it from siblings like get_progress (which reports status) and view_image (which displays images).
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 after queue_workflow via the prompt_id schema hint, and the polling behavior makes the use case clear. However, it does not explicitly state when to use this tool over alternatives (e.g., get_progress) or mention any exclusions/preconditions.
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 disclosure burden. It reveals the sorting order ('newest first') and location ('on spark'), but does not explicitly confirm it is a safe read-only operation, nor does it mention pagination, limits, or return format. The verb 'List' implies read-only, but a more explicit statement would improve 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 a single sentence that is front-loaded with the core action and resource. It contains no filler and every word contributes to meaning.
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 extreme simplicity (no parameters, no output schema), the description covers the essential aspects: what is listed, where, and in what order. It could be enhanced by clarifying the return structure or what 'spark' refers to, but for a listing tool this is adequate.
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 schema is trivially complete. Per the guidelines, a baseline of 4 is appropriate when no parameter information is needed, and the description does not need to explain non-existent parameters.
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 'List' and the resource 'ComfyUI workflow JSON files on spark', with the scope 'newest first'. This distinguishes it from sibling tools like list_outputs and list_models, which target different resources.
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 enumerating workflow files, but does not explicitly compare with alternatives such as read_workflow or write_workflow. No exclusions or context for when to choose this tool over others is provided, so it remains implicit.
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 that the tool returns an image block visible in the conversation, adding context about output format. However, it does not mention error behavior (e.g., missing file) or explicitly state that the operation is read-only, though 'fetch' implies it. Some behavioral depth is missing.
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 outcome. It contains no fluff or unnecessary information.
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, no nested objects, no output schema), the description provides enough information: what it does and what it returns. It could include error handling details or a comparison with view_latest, but it is largely complete for a basic fetch/display tool.
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 provides 100% coverage for the single parameter 'filename' with the description 'Filename in ComfyUI output dir'. The tool description adds no additional semantics beyond the schema, so the baseline of 3 applies.
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 ('Fetch') and resource ('ComfyUI output image') and clearly states the outcome ('return it as an image block visible in the conversation'). This distinguishes it from siblings like list_outputs or download_model, which operate on outputs differently.
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 clear context for when to use the tool: when a ComfyUI output image needs to be displayed in the conversation. It does not explicitly mention alternatives or exclusions, but the purpose is clear enough for an agent to infer when this tool is 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 burden. It adds meaningful validation behavior (content must parse as JSON with nodes+links arrays), but does not disclose overwrite semantics, error handling, or permissions. The overwrite flag exists only in the schema, not in the description, leaving gaps 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 two short, front-loaded sentences. Every word earns its place: it states the action, destination, and a key validation detail without fluff.
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 tool has 3 parameters, all documented in the schema, and no output schema, so the description doesn't need to explain return values. It covers the core action and validation, but leaves out overwrite behavior (though the schema covers it) and the meaning of 'spark' is somewhat ambiguous. Overall, it is fairly complete for a simple write 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 100%, so the baseline is 3. The description adds a structural requirement for the content parameter (must have nodes+links arrays), which is not present in the schema's property description. This enriches the meaning of the content parameter 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 clearly states the tool writes a workflow JSON file to spark, with a specific verb and resource. It also mentions validation, which distinguishes it from sibling tools like read_workflow or queue_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?
Usage is implied by the verb 'write' and the resource 'workflow JSON file', but there is no explicit guidance on when to use this vs. alternatives, nor any mention of prerequisites like the overwrite flag being necessary for existing files. The description does not name sibling tools or provide exclusions.
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 burden. 'List' clearly indicates a read-only operation with no side effects, which is adequately transparent for a simple listing function. It does not disclose output format or edge-case behavior, but these are not critical for a straightforward list 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, concise sentence that precisely conveys the tool's purpose without unnecessary detail or repetition. 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?
For a simple list operation with a single parameter fully documented in the schema, the description provides sufficient context. It specifies the environment (spark) and the resource type (ComfyUI models subdir), 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single required parameter 'kind' with a description and enum values. The tool description adds no additional meaning about the parameter, so the baseline score of 3 is appropriate given the schema already fully documents it.
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 installed model files in a specific subdirectory. The verb 'list' and resource 'model files' are unambiguous, and the scope 'ComfyUI models subdir on spark' distinguishes it from sibling tools like list_outputs and list_workflows.
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 when to use the tool (when needing to list model files) but provides no explicit guidance on alternatives or exclusions. There is no mention of sibling tools or when not to use this tool, leaving the agent to infer from the name and context.
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 provided, so the description carries the burden. It discloses the non-destructive read operation ('list'), scope ('output images on spark'), and ordering ('newest first'). Does not mention pagination or output format, but adequate for a simple read 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?
Single, front-loaded sentence with no filler words. Every word adds value: scope, resource, location, ordering.
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 list tool with 2 optional parameters and no output schema, the description is complete enough. It covers purpose, context, and ordering. Could mention use cases vs view_latest, but not critical.
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 descriptions, so baseline is 3. Description adds no parameter-specific info, relying on the schema for limit and since 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?
Clearly states it lists recent ComfyUI output images on spark, with explicit ordering ('newest first'). The verb 'list' and resource 'output images' are specific, distinguishing it from sibling tools like list_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?
Implies usage for listing generated images but does not explicitly compare with alternatives like view_latest. Provides clear context (on spark, newest first) but lacks explicit when-not-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 of behavioral disclosure. The verb 'Get' implicitly indicates a read-only, non-destructive operation, and listing the specific data points provides clarity on what to expect. However, it does not explicitly state 'no side effects' or address potential costs, leaving a small gap.
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 efficiently lists all relevant outputs without waste. Every word contributes to understanding the tool's 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 zero-parameter, no-output-schema tool, the description is complete. It specifies all distinct data points (RAM, VRAM, GPU, ComfyUI version, queue size) and leaves no ambiguity about what the tool returns. Given its simplicity, no additional context is needed.
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 baseline is 4. The description adds no parameter-specific meaning because there are none, but it effectively explains what the tool returns, which is relevant since there is no output 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 function with a specific verb ('Get') and enumerates the exact resources it retrieves: RAM/VRAM/GPU usage, ComfyUI version, and queue size. This distinguishes it from sibling tools like get_progress or list_models, which target different data.
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 checking system-level stats, but it does not explicitly state when to use this tool over alternatives or any prerequisites. Since it's a simple stats tool, the context is reasonably inferred but lacks explicit 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?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: waits for all variants in parallel, returns all images in a single response, and enforces a max of 8 variants. It does not cover timeout/error behavior, but the timeout_sec_per parameter addresses per-variant timeout.
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 with zero waste: the first states the action and outcome, the second enforces a limit. Front-loaded and easy to scan.
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 core functionality is well-covered: queueing, parallel wait, single-response return, and max limit. No output schema exists, but the description states return type. Missing details like partial failure behavior are minor given the straightforward purpose.
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 meaning beyond the schema by explaining variants as override objects (seeds, prompts, LoRAs, etc.) and adding the max 8 variants constraint not present in 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 has a specific verb 'Queue' and resource 'workflow with N override variants', clearly distinguishing it from sibling queue_workflow by emphasizing parallel execution and single-response image collection. It states exactly 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use for batched variants with parallel waiting, and context from siblings (queue_workflow) indicates this is for multi-variant jobs. However, it does not explicitly state when NOT to use it or name alternatives.
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 of behavioral disclosure. It reveals the asynchronous nature (returns prompt_id, later retrieval) and mentions optional overrides, providing essential context. It does not cover error handling or validation, but the core behavior is transparent enough.
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, information-dense sentence that front-loads the action and includes the return value and next step. No unnecessary words or repetition. Perfectly concise.
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 (nested overrides, no output schema, no annotations), the description covers the essential flow: queue and retrieve. It could add more context about validation, errors, or how overrides are applied, but it is largely complete for typical usage.
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 has only 50% coverage (name and checkpoint have descriptions). The description compensates by listing many overrides (prompt, seed, steps, guidance, sampler, dims, loras), adding meaning beyond the bare types. However, it omits cfg, negative, scheduler, and checkpoint, and uses 'dims' instead of width/height, so it is not fully exhaustive.
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 'Queue' with the resource 'ComfyUI workflow', clearly stating the tool's function. It also mentions the return value (prompt_id) and the follow-up tool (wait_for_image), which distinguishes it from sibling tools that also interact with 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: queue a workflow, then call wait_for_image to retrieve the result. It implies the usage pattern but does not explicitly spell out when to use this versus alternatives like queue_batch or run_comfyscript. Exclusions are not stated, so it doesn't earn a 5.
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, so description carries the full burden. It discloses the execution environment (spark, comfyui venv), auto-prepending of imports/load(), return value (filenames + output tail), and performance timeout considerations. However, it doesn't detail error handling or side effects on the server.
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?
Six dense sentences, each adding value: purpose, when to use, required script structure, capability, return value, and timeout note. No fluff or repetition.
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 code-execution tool with two well-documented parameters, the description is quite complete: it gives environment, usage, return format, and performance caveat. Lacks explicit failure-mode information but that's not critical for selection.
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 covers 100% of params with detailed descriptions and examples, so baseline is 3. The tool description adds extra semantics: auto-prepended imports, availability of all server nodes as functions, and heavy model timeout guidance, which enhance understanding 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?
Clearly states it authors and runs ComfyUI workflows as Python via ComfyScript, with specific reference to complex graphs. Distinguishes from siblings like queue_workflow by noting it's for graphs awkward to express as JSON or GUI-driven.
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?
Explicitly says to use for complex/multi-stage graphs (LTX-2.3, two-stage) and implies JSON/GUI as alternatives. Doesn't name sibling tools but provides context. Missing a direct 'when not to use' but the positive use-case is strong.
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/bernardogv/comfyui-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bernardogv/comfyui-mcp)

Score Badge

Copy to your README.md:

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

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