ComfyUI MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
Many tools have overlapping purposes, especially the image generation suite (text_to_image, flux_text_to_image, dalle3_image, gpt_image_generate) and video generation suite (text_to_video, wan_text_to_video, sora_video_generate). Job-related tools like get_job_status, get_result_images, and wait_for_jobs also have fuzzy boundaries that could cause misselection.
Naming Consistency4/5
Tool names predominantly follow a clear verb_noun snake_case pattern (get_queue, create_workflow, upload_image) with consistent use of get_/list_/create_/delete_ prefixes. Minor exceptions like 'inpaint' and 'suggest_next' deviate slightly, but the overall pattern is predictable and readable.
Tool Count2/5
With 46 tools, the server is heavily over-scoped. While it covers many subdomains, the generation tools are redundant and could be consolidated into generic tools with provider/model parameters. The workflow builder and API node tools add bulk but are useful for advanced users.
Completeness4/5
The tool set provides comprehensive coverage of ComfyUI operations: queue management, system stats, multiple generation paths, file handling, workflow construction/validation/execution, and cloud API node access. Minor gaps like no dedicated audio generation or workflow listing tools exist, but run_api_node covers arbitrary node types.
Average 3.7/5 across 46 of 46 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 provided, the description must fully disclose behavioral traits, but it only states that it frees VRAM and RAM. It doesn't mention side effects (e.g., unloading models, clearing cached memory), whether it interrupts running jobs, or if any prerequisites exist. The parameter names hint at model unloading and cache clearing, but this is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that immediately states the action and target. It contains no filler or redundant information. It sacrifices completeness for brevity, but for pure conciseness it is exemplary.
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 output schema existing, the description is far too sparse for a tool with no annotations. It lacks usage guidance, side-effect disclosure, and any behavioral context, making it insufficient for an agent to safely decide when and how to invoke this 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?
Schema description coverage is 100%, so the schema already fully documents both boolean parameters ('free_memory' and 'unload_models') with descriptions. The tool description itself adds no parameter-level detail, earning the baseline score of 3.
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 uses a specific verb ('free') and a clear resource ('ComfyUI VRAM and RAM'), which clearly states the tool's function. However, it doesn't explicitly distinguish itself from sibling tools, though no sibling seems to serve the same memory-freeing purpose.
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 memory pressure situations or after model execution. The description simply states what it does without any context for use.
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 only states that an AI upscaling model is used, but omits details such as whether the operation is asynchronous, whether it modifies the input or creates a new output, whether it requires significant computational resources, or how the result is returned. The lack of such transparency is a significant gap for a tool that likely performs a heavy image-processing operation.
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 verb. It has no redundant fluff, and it is easy to read. However, it is arguably too sparse, bordering on under-specification, but it remains appropriate for a simple tool and does not waste words.
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 is minimal but the schema provides good parameter context and the output schema exists. The tool has only two parameters, so complexity is low. However, the description does not explain the tool's role relative to sibling tools, nor does it provide any behavioral context beyond the one-line purpose. Given the presence of an output schema, it is not necessary to describe return values, but the missing usage guidance and transparency lower the completeness score. It is minimally viable.
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 covers both parameters exhaustively (100% coverage), including descriptions for input_image (upload first if needed) and upscale_model (auto-selects first available, use list_models). The tool description itself adds no parameter-level meaning beyond what the schema already provides. Baseline 3 applies because the schema does the heavy lifting.
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: 'Upscale an image using an AI upscaling model.' It uses a specific verb ('upscale') and resource ('an image'), which is sufficient to understand its purpose. However, it does not explicitly differentiate from sibling tools like image_to_image, which could also process an existing image, but the term 'upscale' is reasonably 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or exclusions. While the parameter descriptions hint at using upload_image first and listing models, these are schema-level details, not tool-level usage guidance. The description itself is a single declarative sentence with no usage 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, the description carries the full burden of behavioral disclosure. It simply says 'execute a workflow' but does not disclose whether the execution is synchronous or asynchronous, whether it queues jobs, what side effects occur, or whether cancellation/queuing interactions are possible. The wait parameter hints at polling behavior, but the description itself adds no context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, clearly conveying the core purpose. It is under-specified, but for the dimension of conciseness, it is efficient and front-loaded.
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 is an execution action with a rich ecosystem of related tools (queues, jobs, results, etc.). The description provides minimal context: no mention of execution lifecycle, asynchronous behavior, output handling, or relationship to builder tools. The presence of an output schema mitigates some return-value ambiguity, but overall the description is incomplete for a tool of this complexity.
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%: both 'workflow_id' and 'wait' have descriptions in the input schema. The tool description itself adds no additional meaning about the parameters, so the schema carries the burden. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Execute') and resource ('workflow'), and distinguishes itself from sibling tools like create_workflow, validate_workflow, and get_workflow by emphasizing 'built with builder tools'. This clearly identifies the tool's primary action and 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing to create/validate a workflow first, nor any explicit reference to related tools like get_job_status or wait_for_jobs for asynchronous execution scenarios.
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 for behavioral disclosure. It only states the function ('view or download') and does not mention whether the URL is temporary, requires authentication, or how it handles errors, offering minimal behavioral 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, direct sentence that front-loads the core action and resource. There is no redundant or filler content, making it highly concise.
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 URL retrieval tool, this is a minimum viable description. It lacks usage guidance and behavioral transparency, but the presence of an output schema and well-documented parameters partially compensates. The description also introduces ambiguity by mentioning video/audio while the schema example only shows .png.
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 includes descriptions for all three parameters, and the description adds no extra parameter semantics. With 100% schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('URL for a ComfyUI image/video/audio'). It is not a tautology and provides enough specificity to distinguish it from many siblings, though it could more explicitly contrast with similar tools like get_result_images.
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. The description lacks context about prerequisites, use cases, or situations where another tool would be more appropriate, leaving the agent without selection guidance.
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 carry the full burden of behavioral disclosure. It only mentions parameter optionality and does not describe side effects, prerequisites (e.g., image upload), output behavior, or limitations. The description adds minimal behavioral context beyond the basic 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 two sentences, front-loaded with the primary purpose and followed by a concise note about optional parameters. Every sentence contributes value, and there is no redundant or irrelevant content.
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 complex (12 parameters) but has an output schema, which reduces the need to describe return values. The description covers the core purpose and optionality but omits workflow context (e.g., job status, result retrieval). Still, the schema provides substantial details, making the description minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions, so baseline is 3. The description adds a general statement that all parameters except prompt and input_image are optional with sensible defaults, which is informative but not detailed. It reinforces the schema but does not substantially augment parameter meaning.
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 states a specific action: 'Transform an existing image guided by a text prompt.' This clearly identifies the verb and resource, and the mention of 'existing image' distinguishes it from text-to-image tools. However, it does not explicitly differentiate from similar image-editing siblings like inpaint or upscale_image, so it stops short of full sibling 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 over alternatives. It neither names alternatives nor describes typical use cases beyond the basic transformation. Given many overlapping sibling tools (inpaint, upscale_image, text_to_image), the lack of usage context is a notable gap.
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. It only restates the basic 'list' action and provides no additional context such as output format, potential side effects, or that empty input returns folder names. The schema covers parameter behavior, but the description itself is thin.
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 directly states the tool's purpose. No unnecessary words or filler.
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 one-parameter tool with a complete schema and output schema, the description is adequate but not complete. It lacks usage guidance and does not differentiate from sibling tools, making it only minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains the folder parameter's behavior. The description adds no parameter-specific meaning, but the schema handles it well, giving a baseline score of 3.
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 lists models in ComfyUI, using a specific verb and resource. However, it does not distinguish itself from sibling tools like list_files or list_samplers_and_schedulers, which could also be used for listing.
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 gives no guidance on when to use this tool versus alternatives. It does not mention that it only lists models in ComfyUI or how to select a specific folder, leaving the agent without context for choice.
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 present, so the description carries the full burden. It only says 'generate images' and mentions parameter optionality. It does not disclose that generation may be asynchronous, require job tracking, or have resource implications. The description is minimal and lacks behavioral context.
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 concise (two sentences) and front-loaded with the core purpose. The second sentence about customization is somewhat vague but serves as a useful expectation-setter. It is efficient without unnecessary detail.
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 a rich schema and output schema, the description misses critical context about how the tool integrates with other tools, such as job submission, result retrieval, or asynchronous behavior. For a complex generation tool with sibling workflow tools, this is a significant completeness gap.
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 every parameter already detailed in the input schema. The description only adds the generic note that parameters are optional with defaults, which is redundant with schema default values. It does not enrich parameter understanding beyond what the schema provides.
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: 'Generate images from a text description.' This is a specific verb+resource combination that distinguishes it from image-to-image or video generation. However, it does not differentiate among sibling text-to-image variants like flux_text_to_image or dalle3_image, making the choice among them ambiguous.
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 basic guidance: all parameters except prompt are optional with sensible defaults, implying users can customize. It does not state when to use this tool versus alternatives, nor any prerequisites or exclusions. The guidance is 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries no behavioral disclosure. It does not mention whether the workflow is persisted, what the response contains, whether creation can fail, or any side effects. The description is purely a restatement of the tool's name.
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 with no wasted words. It is front-loaded with the main action and successfully communicates the core purpose in minimal space.
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 and fully documented parameters, the description lacks context about the workflow lifecycle. It does not clarify how this relates to siblings like 'execute_workflow', 'add_node', or 'validate_workflow', nor does it mention practical usage scenarios. For a workflow management system, this is insufficient.
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 provides 100% parameter descriptions, so the baseline is 3. The tool description adds no extra parameter semantics beyond mentioning that creation can optionally start from a template, which is already covered in the schema's template field description.
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 ('Create') and resource ('workflow'), and adds an optional qualifier ('optionally from a template'). This clearly distinguishes it from siblings like 'get_workflow', 'execute_workflow', or 'validate_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 description implies when to use the tool (when you need a new workflow) but provides no explicit guidance on when not to use it or alternatives such as 'add_node' or 'execute_workflow'. There is no clear usage context beyond the obvious.
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 full responsibility for behavioral disclosure. It only states the basic get operation without revealing important traits such as whether it returns incomplete outputs for running jobs, error behavior for invalid prompt IDs, or if it blocks until completion.
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, efficient sentence with no unnecessary words. It is concise and front-loaded, though it could potentially include more contextual detail without becoming verbose.
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's simplicity (one fully documented parameter, output schema present), the description covers the core purpose. However, it lacks usage context and behavioral caveats, making it only minimally complete for an agent deciding when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the prompt_id parameter (coverage 100%), and the description adds no additional semantics beyond what the schema provides. The baseline score of 3 is appropriate because the schema handles the parameter documentation.
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 ('Get') and the resource ('status and outputs of a queued ComfyUI job'). It distinguishes from sibling tools like get_queue (list jobs) and get_history (list history) by focusing on a single job's status and outputs.
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 does not mention exclusions, prerequisites, or compare with sibling tools like wait_for_jobs or get_result_images.
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 full responsibility. It reveals that the tool mutates a node's inputs, but does not disclose whether updates are partial/full, error conditions, or return behavior. This is inadequate 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, efficient sentence with no redundant words. It is appropriately sized for the tool's simplicity, front-loading the verb and object.
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 that this is a mutation tool with no annotations and minimal description, it lacks important context about side effects, validation, or return values. The output schema exists but the description still leaves the agent guessing about behavior.
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 of all three parameters, and the schema descriptions provide meaningful details (e.g., the inputs JSON format). The tool description itself adds no parameter information, so baseline 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 clearly states a specific verb ('Update') and resource ('inputs') plus the target ('existing workflow node'). This distinguishes it from sibling tools like add_node or remove_node, which serve different purposes.
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 gives no guidance on when to use this tool versus alternatives, nor does it mention any preconditions or exclusions. It simply states the action without contextual usage info.
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 disclose behavioral traits such as irreversibility, scope (e.g., affects only pending items), or side effects. The description merely states the action without any additional context, leaving the destructive nature and limitations unaddressed.
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 conveys the core function without any fluff. Every word is useful, and it is appropriately front-loaded with the action.
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 tool with one parameter and an output schema, the description is minimally viable but lacks important context such as differentiating from cancel_job (running jobs) and noting the permanence of deletion. It covers the basics but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage of the only parameter, prompt_ids, with a clear description. The tool description adds no further semantic meaning, so the baseline score 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 'Delete specific items from the ComfyUI queue' clearly states the verb (delete), resource (items in the ComfyUI queue), and scope (specific, not all). This distinguishes it from siblings like clear_queue (all items) and cancel_job (running jobs), making its 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?
The description provides no guidance on when to use this tool over alternatives. It does not mention that it is for pending queued items versus running jobs, nor does it name alternatives like cancel_job or clear_queue. No exclusions or prerequisites are stated.
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 burden of behavioral disclosure. The verb 'Get' implies a non-destructive read operation, but the description doesn't explicitly state that it has no side effects or limitations. It adds minimal context beyond the tool's name.
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 information. It is concise and efficient, earning a high score for structure.
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's simplicity and the presence of an output schema, a minimal description is somewhat acceptable. However, it lacks context about the relationship to other history-related tools (e.g., delete_history_items) and doesn't mention optional parameter behavior beyond the schema. It is adequate but not comprehensive.
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 provides full description coverage for both parameters (max_items, prompt_id), so the description itself adds no additional parameter semantics. Per the rubric, a baseline of 3 is appropriate when schema already documents parameters clearly.
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 'Get ComfyUI execution history' uses a clear verb and resource, distinguishing it from sibling tools like get_queue and get_job_status. However, it doesn't explicitly differentiate itself or elaborate on what 'history' encompasses, so it's slightly below a perfect score.
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 get_queue or get_job_status. There is no mention of exclusions, prerequisites, or typical scenarios, leaving the agent to infer usage from the name and schema alone.
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 present, so the description carries the full burden. It states the basic functionality but does not disclose any behavioral traits such as read-only safety, hidden files, or any limitations.
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 is easy to parse and front-loaded with the key information. 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 tool with one fully described parameter and an output schema, the description is adequate. It could be improved with usage guidance, but the complexity is low and schema covers most operational details.
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% and the parameter description clearly explains the allowed values ('output', 'input', 'temp'). The tool description adds no extra meaning beyond the schema, but the schema already does the heavy lifting.
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 (files in a ComfyUI directory). It distinguishes itself from sibling list tools like list_models and list_samplers_and_schedulers by specifying files and directory context.
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 or when not to use it. The description only states what it does, leaving the agent to infer usage from the name and parameter.
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?
Description only states the action without disclosing side effects. As a destructive clearing operation, it does not warn about permanence or scope (e.g., impact on running jobs). With no annotations, the description carries full burden but fails to offer safety or behavioral 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?
Single sentence with no filler, effectively front-loading the verb and object. 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?
For a simple 0-param tool with an output schema, the description is close to adequate. However, it omits behavioral details like irreversibility and does not clarify its relationship to overlapping queue-management siblings, leaving a slight gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, and the empty schema means coverage is trivially 100%. The description adds nothing about parameters, but baseline for 0-param tools is 4 per rubric.
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?
Description uses specific verb 'clear' with resource 'all pending items from the ComfyUI queue', clearly distinguishing it from read-oriented siblings like get_queue. No ambiguity about the action or 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?
No indication of when to use this tool versus alternatives like delete_queue_items or cancel_job. There are no usage conditions, prerequisites, or explicit exclusions provided.
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. However, it simply restates the tool's purpose without disclosing important traits such as irreversibility, potential side effects on running jobs, or whether deletion is permanent. This is a significant gap for a destructive 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 clear sentence with no wasted words. It effectively communicates the core function without unnecessary elaboration.
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 one-parameter tool with an output schema, the description is minimally adequate but lacks context about when to use it, what 'history' means, or the consequences of deletion. It does not benefit from annotations to fill gaps, making it a bare-minimum viable description.
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 fully describes the only parameter (prompt_ids) as a comma-separated list of prompt IDs, so schema coverage is 100%. The tool description adds no additional parameter context, but the baseline for full schema coverage is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Delete specific items from ComfyUI execution history.' It uses a specific verb ('Delete') and resource ('ComfyUI execution history'), and it is distinguishable from sibling tools like delete_queue_items and clear_queue by focusing on history items rather than queue items.
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 selective deletion from history but provides no explicit guidance on when to use this tool versus alternatives such as clear_queue or delete_queue_items. It does not mention exclusions or conditions, leaving the agent to infer the scope based on the tool name and sibling 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?
No annotations are provided, so the description must carry the behavioral transparency burden. It only states the action without disclosing side effects (e.g., whether the job is terminated abruptly, if results are discarded, or if cancellation is reversible). This is a significant gap for a mutating 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 with no filler, front-loading the core action. It is concise and appropriately sized for the tool's simplicity.
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 no parameters and an output schema, so the description's job is mainly to clarify the action. It does that, but could be more complete by noting distinctions from related tools (e.g., cancel works on running jobs only, not queued ones). Overall, it is adequate but not exceptionally informative.
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?
There are zero parameters, so the schema inherently covers 100% of parameters. The description does not need to elaborate on parameter semantics, and it doesn't, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'cancel' and identifies the resource as 'currently running ComfyUI job', clearly distinguishing from queue-clearing tools like clear_queue. It precisely states the tool's 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 guidance is provided on when to use this tool versus alternatives like clear_queue or delete_queue_items. The description does not mention exclusions or specific scenarios, leaving the agent to infer usage from the 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the operation ('fill in') and parameter optionality. It does not disclose that this is a generative, potentially non-deterministic operation, how long it may take, whether it blocks, or that it returns an image. The phrase 'Change any parameter to customize' adds minimal behavioral 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 two sentences: the first states the core function, the second clarifies parameter optionality. No filler or redundancy; it is appropriately front-loaded and earns its place.
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 moderate complexity (12 parameters, 3 required), the description, combined with 100% schema coverage and an output schema, is adequate. It clearly identifies the core action and parameter defaults. It could mention the need for both source and mask images, but this is already explicit in the schema's required fields and parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by stating that all parameters except the three required ones are optional with sensible defaults, which helps an agent avoid unnecessary configuration. However, it does not elaborate on any individual parameter beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-object pair ('Fill in masked regions of an image with AI-generated content'), clearly identifying the tool's purpose and distinguishing it from image generation or upscaling siblings. The scope is well-defined through the reference to masks.
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 in contexts where an image has masked regions to fill, but it provides no explicit guidance on when to choose this tool over alternatives like image_to_image or text_to_image. No exclusions or alternative tool mentions 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it performs a search without disclosing whether the operation is read-only, what the response format is (though output schema exists), or any potential limitations. For a search tool, this lack of context leaves the agent without clear expectations about side effects or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core action and resource, and includes all key filter dimensions without any wasted words. It is appropriately sized for a tool of this simplicity.
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 simple search purpose, the presence of a comprehensive input schema, and an output schema, the description provides sufficient context for an agent to select and invoke the tool. However, it lacks explicit guidance on when to use this over sibling node-related tools, so it falls slightly short of being 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?
The input schema covers all four parameters with detailed descriptions (100% coverage), so the description adds little beyond summarizing the filter dimensions. The baseline of 3 applies because the schema already documents each parameter effectively, and the description does not add new semantic 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 uses the specific verb 'Search' and identifies the resource 'ComfyUI nodes' while listing the search dimensions (name, category, input/output type). This clearly distinguishes it from sibling tools like get_node_schema, which retrieves a schema for a specific node.
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 should be used when users need to find nodes matching name, category, or input/output type criteria. However, it does not explicitly mention when not to use it or compare it to alternatives like list_api_nodes or get_node_schema, so usage 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.
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 behavioral disclosure burden. It explains that the tool analyzes and checks for specific issues, which implies a read-only operation, but it does not explicitly state that it does not modify the workflow or describe the format of the suggestions. The listing of checks adds some transparency, but side effects and output details remain undisclosed.
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 concise, two sentences, with the main purpose front-loaded in the first sentence and specific checks following. Every word earns its place; no filler or 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 one well-documented parameter and an output schema present, the description provides adequate context for basic usage. It lists the checks performed but does not mention prerequisites (e.g., workflow must exist) or whether the tool is read-only. However, the simplicity of the tool and schema coverage make this sufficient for most cases.
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 100% description coverage for the single parameter (workflow_id: 'The workflow to analyze.') The tool description adds no new meaning about this parameter beyond what the schema already states, 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 clearly states the tool analyzes a workflow and suggests next steps, listing specific checks (unconnected inputs, unused outputs, missing output nodes). This distinguishes it from sibling tools like validate_workflow (validation) and get_workflow (retrieval), giving a specific verb+resource+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?
No guidance on when to use this tool versus alternatives. The description implies it is for getting next-step suggestions after building a workflow, but it does not mention exclusions or distinguish from validate_workflow or other analysis tools. There are no when-to-use or when-not-to-use instructions.
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 of behavioral disclosure. It only states the upload action but does not mention side effects, overwrite behavior, return values, or any restrictions, leaving significant behavioral ambiguity for a file-writing 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 is front-loaded and contains no unnecessary words. It effectively communicates the core purpose.
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 simplicity of the tool and the presence of both input and output schemas, the description is mostly complete. It lacks some context about behavioral nuances, but the schemas fill in parameter details, making it adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it merely restates the action without elaborating on parameters like overwrite or subfolder.
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 file), and the destination (ComfyUI's input directory). It is specific and distinguishes from siblings like upload_mask by focusing on image files rather than masks.
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 use when you have a local image file to upload to ComfyUI, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or compare with similar tools like upload_mask.
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 the auto-connection behavior but does not explain its side effects, potential to override existing connections, or failure modes. This leaves 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 a single, well-structured sentence with no filler. It front-loads the action and resource and includes a relevant qualifier, making it efficiently informative.
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?
While the output schema and parameter schemas exist, the description lacks detail on edge cases, validation behavior, or what happens when auto-connection fails. It is adequate but not complete for a workflow-modifying tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of 'auto-connection' adds minimal meaning beyond the schema's detailed explanation of inputs connections. No additional parameter semantics are provided.
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 'Add a node to a workflow with auto-connection of typed inputs' clearly states a specific action (add) and resource (node in a workflow). The auto-connection detail distinguishes it from sibling tools like remove_node and set_inputs.
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 adding nodes but does not explicitly state when to use it versus alternatives or mention any exclusions. There is no guidance about prerequisites like workflow existence or node class validity.
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?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It states the copy action but doesn't mention whether existing files in the input directory will be overwritten, permission requirements, or error conditions. For a mutation-like tool, this lack of transparency is a notable 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 two sentences, front-loaded with the core action. The example is useful and adds context without being verbose. Every sentence 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 relatively simple, the schema covers all parameters, and an output schema exists. The description explains the purpose and main use cases. However, the lack of behavioral details (e.g., overwrite behavior) and absence of annotations leaves gaps in understanding for a mutation 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 input schema has 100% coverage, with each parameter clearly described (e.g., filename examples, subfolder usage). The description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Copy a file from ComfyUI's output directory to input directory.' This is a specific verb+resource pair that clearly distinguishes it from sibling tools like upload_image (which uploads external files) or get_result_images (which retrieves outputs). The phrase 'Makes generated files... available as inputs' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: 'For example, copy a generated image to use it in image_to_image, image_to_video, or run_api_node.' This implies when to use the tool. However, it doesn't explicitly name alternative tools or exclusion scenarios, so it doesn't fully meet the 'when-not-to-use' bar.
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 for behavioral disclosure. It mentions the need for a COMFY_API_KEY but does not disclose whether the tool is asynchronous, how results are retrieved, or potential side effects like queue submission or cost. This is a significant gap for a generation tool that likely submits a job to the ComfyUI queue and requires later retrieval.
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 three sentences long and front-loads the core purpose. Every sentence contributes: the first states what it does, the second explains usage modes, and the third clarifies prerequisites. There is no redundancy or filler.
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 8-parameter complexity and the presence of an output schema, the description is adequate for basic invocation but omits important workflow context. It does not mention that input_image must be uploaded first (instead the schema does), nor does it hint at how to poll for results (though sibling tools like wait_for_jobs imply this). The description and schema together cover invocation, but the description alone leaves the overall process partially 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 input schema provides rich descriptions for all 8 parameters, so the baseline is 3. The description adds an aggregate note that 'All parameters except prompt are optional', which is helpful. However, it largely restates the prompt's dual role already present in the schema (text description or edit instruction), so it does not significantly enhance parameter 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?
The description clearly states 'Generate or edit an image using GPT Image via Comfy.org API', giving a specific verb, resource, and API context. This distinguishes it from sibling tools like dalle3_image or flux_text_to_image by focusing on the GPT Image model. It also enumerates the two modes: generating from text and editing an existing image.
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 on when to use the tool: 'Can generate from text alone, or edit an existing image with a prompt.' It also notes that 'All parameters except prompt are optional,' which gives practical guidance. However, it does not explicitly mention alternative tools or when not to use this one, so it lacks explicit exclusionary 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently mentions the required COMFY_API_KEY and that all parameters except prompt are optional, which is valuable. But it omits other relevant behavioral traits such as whether the tool submits a job asynchronously or returns a download URL, which is especially important given the sibling queue/job management tools.
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 exceptionally concise—two sentences that immediately state the core purpose and then add only high-signal facts (text/image modes, optional parameter behavior, API key requirement). Every word earns its place, and the structure front-loads the most important information.
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 is reasonably complete for a tool with an output schema and full parameter documentation, but it leaves out the workflow context. It does not mention that video generation likely occurs via a job queue or that the agent may need to poll for status, even though sibling tools like get_job_status and wait_for_jobs strongly suggest this. This gap makes the description adequate but not fully comprehensive.
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% description coverage, with each parameter including defaults and valid values. The description adds only a high-level statement that all parameters except prompt are optional, which is already evident from the schema. According to the baseline rule, a score of 3 is appropriate when the schema does the heavy lifting.
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 'Generate' and the resource 'a video using Sora 2 via Comfy.org API', immediately conveying what the tool does. It also distinguishes itself from sibling video generation tools by naming Sora 2 and specifying two modes (text-only or image animation), making its 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context by noting that generation can be text-only or animate an existing image, and it highlights that all parameters except prompt are optional. However, it does not explicitly name alternative tools (e.g., text_to_video, wan_text_to_video) or state when to prefer this tool over them, relying on the 'Sora 2' reference to imply the use case.
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. It states the action ('Get metadata') but does not disclose behavioral traits such as whether it is read-only (presumably), what happens on missing/invalid files, whether it requires network/local access, or any error handling. The description provides only surface-level intent without deeper behavioral 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 concise and front-loaded: a clear one-line purpose followed by an optional usability hint. Every sentence serves a purpose—defining the operation and indicating the kind of information obtainable. No wordiness or 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 simple two-parameter tool, full schema coverage, and the presence of an output schema, the description covers the essential context. It could benefit from a note about error handling or prerequisites (e.g., folder must exist), but overall it is sufficient for a metadata retrieval operation. The lack of such details prevents a perfect score.
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%; both parameters are described ('Model folder name', 'Model filename within the folder'). The description adds minimal extra meaning by mentioning 'safetensors' and the type of metadata, but it doesn't elaborate on the parameters beyond the examples in the schema. This meets the baseline for well-documented parameters, without adding significant semantic value.
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: 'Get metadata from a safetensors model file.' It names the resource (safetensors model file) and the operation (get metadata), which distinguishes it from siblings like list_models (listing models vs. inspecting a single model's metadata). The added use-case line further clarifies intent.
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 clear context on when to use: 'Useful for inspecting what a model was trained on, its configuration, resolution, license, etc.' This implies it's the right tool for reading model metadata. It doesn't explicitly mention alternatives or when not to use, but the sibling list includes tools like list_models that serve different purposes, and the description makes the appropriate use case obvious.
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 states the tool returns the 'full input/output schema,' which provides some behavioral detail, but it does not mention side effects (e.g., read-only nature), error handling, or prerequisites like the node class needing to exist. It is not misleading but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that is front-loaded with the action and resource. There is no wasted wording, and it is appropriately sized for a simple getter tool.
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 tool with one parameter and an output schema (which likely documents return values), the description is sufficient. It could note that the node class must be valid or exist, but the simplicity of the operation makes this a minor gap, not a significant omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the only parameter (class_type) with an example. The description adds context about the schema being 'full input/output,' but it does not add further meaning to the parameter itself. Baseline of 3 applies due to 100% 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 tool's action: 'Get the full input/output schema for a ComfyUI node class.' It uses a specific verb ('Get') and resource ('full input/output schema'), and this distinguishes it from sibling tools like get_workflow or search_nodes by focusing specifically on node class schemas.
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 when you need a node's schema, but it does not explicitly state when to use this versus alternatives like search_nodes or get_features. No exclusions or alternative tool guidance is provided, so it is only minimally useful for choosing between tools.
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 states it returns the 'full' graph state with type information, indicating a comprehensive read operation. However, it does not disclose error behavior, prerequisites, or potential performance implications beyond the word 'full'.
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 unnecessary words. It effectively communicates the tool's core function in ten 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?
The description is adequate for a simple one-parameter getter tool, especially since an output schema exists. It covers what the tool does, but could benefit from a note on when to use it or prerequisites, though these are not essential given the low complexity.
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 already provides a clear description for the only parameter ('The workflow to inspect'), so coverage is 100%. The tool description adds context about what is retrieved (full graph state with types) but does not add specific parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('full workflow graph state with type information'). This distinguishes it from sibling tools like get_queue, get_job_status, or get_node_schema, 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 its usage for retrieving a workflow graph but provides no explicit guidance on when to use it versus alternatives, nor any exclusions or related tool references. The purpose is clear enough that an agent can infer applicability, but there is no proactive direction.
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 burden of behavioral disclosure. It does provide transparency into the operational steps (decompose into frames/audio, batch frames, combine audio, reassemble). However, it omits important behavioral details such as whether input videos must have matching resolutions, how incompatible audio modes are handled, or potential performance/memory implications. It adds some process context but lacks significant limitations 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 concise and front-loaded: the first sentence immediately states the purpose, followed by a short, clear explanation of the process. Every sentence adds value, with no redundancy or superfluous details. It is efficiently structured for quick comprehension.
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 complexity of video merging, the description provides a high-level overview that, combined with the rich input schema and presence of an output schema, is mostly complete. However, it lacks context about video compatibility constraints (e.g., resolution, codec, frame rate) and edge cases, which could be important for the agent to decide invocation parameters or anticipate failures. Still, it covers the essential operation and process adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents all four parameters including their types, defaults, and descriptions. The tool description does not add any additional meaning or context beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Merge multiple videos into a single video.' It also explains the internal process of decomposing, batching, and reassembling, which distinguishes it from video generation tools like text_to_video or image_to_video. The purpose is unambiguous and well differentiated from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (merging videos) but does not explicitly state when to use this tool versus alternatives or provide exclusions. For example, it doesn't mention differences from video generation or editing tools. The context is clear from the name and description, but no alternative comparisons or prerequisites 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 burden of disclosing behavioral traits. It does mention that dangling connections are cleaned up, which is useful side-effect information. However, it does not disclose irreversibility, failure conditions, or any permissions required, 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 a single, concise sentence that front-loads the core action and includes an additional behavioral detail. Every word earns its place, with no unnecessary elaboration.
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 moderate complexity, full schema coverage, and the presence of an output schema, the description is fairly complete. It explains the core function and a key side effect, though it could benefit from noting irreversibility or prerequisites.
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 covers both parameters with descriptions, so the baseline is 3. The description adds context about 'cleaning up dangling connections' but does not elaborate on the parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') with a clear resource ('node from a workflow') and adds relevant scope ('clean up dangling connections'). It is easily distinguished from sibling tools like delete_history_items or delete_queue_items, which target different entities.
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 removing a node from a workflow, but does not explicitly state when to use it over alternatives or any exclusions. There is no mention of related tools like add_node or validate_workflow, leaving the usage context somewhat implied.
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 burden. It adds valuable context about parameter optionality and the required API key. But it doesn't disclose whether the call is synchronous, how errors are reported, or any rate limits or costs, leaving behavioral expectations 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 sentences: purpose first, then key usage note. Every sentence earns its place without repetition or filler. The structure is clean and front-loaded.
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 an output schema, so return values are covered there. The description includes purpose, auth requirement, and a clear alternative, which covers the main contextual needs. It falls short only in not contrasting with sibling image-generation tools, but the alternative statement compensates.
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 covers 100% of parameters with descriptions and defaults, so baseline is 3. The description adds aggregate information ('All parameters except prompt are optional') which is helpful but already derivable from the schema. No additional semantic or format details beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Generate an image using DALL-E 3') and the provider ('Comfy.org API'). It distinguishes itself from siblings by naming the model and provider, and explicitly redirects other providers to run_api_node().
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit alternative for other API providers ('use run_api_node() with list_api_nodes()') and states a prerequisite ('Requires COMFY_API_KEY'). However, it doesn't compare with sibling image tools like text_to_image or gpt_image_generate, so usage context is partial.
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 of explaining behavior. It states that the tool returns a dict of supported features, which implies a safe read operation, but it does not explicitly confirm that it is read-only, require no authentication, or mention any limitations. The description adds some value by listing example contents but lacks explicit behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: one sentence states the purpose, followed by a short 'Returns' line giving example contents. Every word earns its place, and there is no redundant or boilerplate text.
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 getter with no parameters and an output schema, the description adequately covers return value and key examples. It could have expanded on edge cases or the exact shape of the returned dict, but the existing detail is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the schema coverage is 100%. According to the calibration, the baseline for zero parameters is 4, and the description does not need to explain parameters. It additionally clarifies the return type, which is helpful.
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 ('Get') and clearly identifies the resource ('ComfyUI server feature flags and capabilities'). It distinguishes itself from siblings like get_system_stats by focusing on feature flags and capabilities rather than runtime statistics.
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 purpose is clear, the description provides no explicit guidance on when to use this tool versus alternatives (e.g., get_system_stats or get_queue). There is no mention of exclusions or preferred contexts, so the usage is implied rather than specified.
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 correctly implies a read-only operation ('Get'), but it does not disclose behavior for incomplete jobs (e.g., error vs. empty result), output format, or any pagination/ordering details. 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?
The description is a single, front-loaded sentence with no wasted words. It conveys the action, scope, and necessary condition 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 one-parameter getter with an output schema, the description is largely complete: it identifies the input (completed job's prompt ID) and the result (all output images). It does not explain what happens if the job is not completed, but the output schema likely covers return structure, making this sufficient for typical use.
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 covers the sole parameter 'prompt_id' with a clear description ('The prompt ID of the completed job'). Since schema coverage is 100%, the description adds no additional parameter semantics beyond what the schema already provides, justifying the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Get all output images') and clearly scopes it to 'a completed ComfyUI job.' This distinguishes it from sibling tools like get_job_status (status only) and get_image_url (a single image URL).
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 when to use the tool: after a ComfyUI job has completed. However, it does not explicitly state when not to use it or mention alternatives such as get_image_url for individual images, so it falls short of full 5-level 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?
With no annotations, the description carries the burden. It adds context that these are cloud-based and run via the Comfy.org API proxy, which is useful. However, it does not disclose potential behaviors like read-only status, pagination, or network dependence. For a simple listing tool, the added context 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?
The description is three sentences: a clear headline, a brief context about the resource type, and actionable next steps. Every sentence adds value, and the structure is front-loaded with the core purpose.
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 is simple with no required parameters and an output schema present. The description explains what the tool lists, the nature of the nodes, and how to proceed (schema lookup then execution). It could mention limitations like provider availability, but the existing coverage is sufficient for this level of complexity.
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%, so the schema fully documents the two optional parameters (query and output_type). The description adds no extra parameter semantics beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List available API nodes' which is a specific verb+resource. It lists concrete examples (Kling, Runway, Luma, etc.) and differentiates from siblings like get_node_schema (details) and run_api_node (execution) by framing this as the discovery step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: list nodes first, then get schema, then run. It names the alternative tools (get_node_schema, run_api_node) in a natural workflow. It does not explicitly state when not to use this tool, but the workflow implies its role as a starting point.
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 meaningful behavioral details: alpha channel extraction and that white areas are inpainted. But it leaves gaps—it doesn't say whether the original file is overwritten/processed, whether overwrite flag controls file collision behavior, or what the response contains. The phrase 'processed to extract the alpha channel' is somewhat ambiguous about what exactly is stored.
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 extremely concise: two sentences that front-load the core function and then add essential context. No wasted words or repetition of schema contents.
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 moderate complexity, the presence of an output schema, and the clear purpose/behavior description, it is fairly complete for an agent to decide when to invoke it. It slightly lacks explicit guidance on when to choose `upload_image` instead, but the mask-specific processing makes the use case clear enough.
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 all parameter meanings are already in the schema. The description does not add per-parameter semantics beyond the schema; it merely provides high-level purpose. This meets the baseline but does not exceed 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 uses a specific verb ('Upload') and resource ('mask image to ComfyUI's input directory'), and immediately differentiates itself from the sibling `upload_image` by noting mask-specific processing for inpainting workflows. This makes the tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the intended use case ('for use with inpainting workflows') and explains the mask semantics (white areas inpainted), giving the agent enough context to choose it over generic `upload_image`. However, it does not explicitly mention alternatives or exclusion scenarios when this tool should not be used.
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 usefully discloses that all non-prompt parameters have sensible defaults and that the model and text encoder are auto-detected. However, it omits details about output handling, error conditions, or resource implications (e.g., computation time, VRAM usage).
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 with no filler. The first sentence states the purpose and model, and the second communicates key behavioral shortcuts. It is well-structured and front-loaded.
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 14 parameters, the description is compact, but the schema describes each parameter, and an output schema exists to cover return values. The description covers the most important behavioral aspects (defaults, auto-detection) and is sufficient for an agent to decide to use the tool. It could mention how to direct the output, but that is likely covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3. The description adds value by clarifying that all parameters except prompt are optional with sensible defaults and that diffusion_model and clip_name with empty strings are auto-detected, which explains the schema's default values and reduces uncertainty about model selection.
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 ('Generate video') and identifies the exact resource ('Wan 2.2 (local model)'), which clearly differentiates it from sibling tools like text_to_image or wan_image_to_video. The phrase 'from text' makes the modality explicit.
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 suggests the use case (text-to-video with Wan 2.2) and adds 'local model' as context, but it does not explicitly contrast with alternatives such as text_to_video or wan_image_to_video. There is no when-not-to-use guidance or mention of sibling tools.
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 states 'recent' and 'for debugging', which gives some behavioral context, but does not explicitly disclose that the operation is read-only, potential truncation, or ordering. For a simple get operation, this is acceptable but leaves 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 sentence of 10 words that efficiently conveys the purpose. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and an output schema, the description is complete. It identifies the server, the resource, the recency, and the purpose. The output schema handles details about the return value, so the description need not explain them.
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 100% coverage for the single parameter max_entries with a clear description. The tool description adds no extra parameter information, so the baseline of 3 applies as the schema already does the heavy lifting.
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 'Get' with a clear resource 'ComfyUI server log entries' and adds scope ('recent') and purpose ('for debugging'). This distinguishes it from sibling tools like get_queue or get_history, which deal with other resources.
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 phrase 'for debugging' clearly indicates a usage context (troubleshooting or monitoring). However, it does not explicitly mention alternatives or when not to use this tool, but given the specificity of 'log entries', the context is unambiguous.
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 model is local and that parameters have sensible defaults, but it does not mention execution behavior such as asynchronous processing, resource usage, or output delivery. The local vs cloud distinction is helpful but does not go far enough to fully disclose behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first states the core function, the second gives usage guidance. Every sentence adds value, and it is front-loaded.
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 covers purpose, local vs cloud alternatives, and parameter optionality, but it does not explain whether the tool runs asynchronously or how the generated video is returned. Given the complexity of video generation and the presence of job management siblings, this is a notable gap. However, the output schema likely covers the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all parameters. The description adds a general statement that all parameters except prompt are optional with defaults, but that is also already reflected in the schema (default values and required list). Thus no additional meaning beyond schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Generate a video from a text description using LTX-Video (local model)', which is a specific verb and resource. It also distinguishes from cloud alternatives by mentioning sora_video_generate() and run_api_node(), so it clearly differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use vs alternatives: 'For cloud-based video generation, use sora_video_generate() or run_api_node() with Kling/Runway/Luma/etc.' It also tells the agent that all parameters except prompt are optional with defaults, providing customization guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: local model execution, auto-detection of Flux model and CLIP encoders, and default 1024x1024 high-quality output. It does not mention potential runtime costs or failure modes, but the main behavioral traits are conveyed.
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 three short sentences with no fluff. Each sentence earns its place: purpose, parameter flexibility, and default behavior. It is 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?
For a text-to-image tool with an output schema, the description covers the essential operational context: local model, defaults, auto-detection, and output size. It could be more complete with explicit guidance on when to use this versus sibling generation tools, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all 11 parameters with high coverage, so the baseline is 3. The description adds meaningful high-level semantics by stating that only prompt is required and all other parameters have sensible defaults, while also explaining auto-detection behavior for model-related 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 opens with 'Generate images using Flux (local model)', which is a specific verb plus a clearly named resource. It distinguishes this tool from siblings like text_to_image by specifying Flux and local 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 description implies usage through 'All parameters except prompt are optional with sensible defaults' and 'Auto-detects installed Flux model', but it never explicitly states when to choose this tool over alternative image generation tools. No exclusions or alternative tool mentions are provided.
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 that it uses a local model and that parameters have sensible defaults, but it does not describe side effects (e.g., output storage, resource usage), potential failure modes, or whether it runs synchronously. The existence of an output schema reduces the need to detail return values, but behavioral transparency remains limited.
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 concise sentences. The first states the purpose, and the second covers optionality and alternative tools. No waste, front-loaded, 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?
Given the tool's complexity (13 params), the description plus schema covers the essential purpose, usage, and parameter semantics. It points to alternatives and mentions the local nature, which is important context. However, it lacks information about the execution flow (e.g., job-based or synchronous) and does not explicitly mention other local alternatives, but the output schema and sibling tools help fill gaps.
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 provides 100% coverage with detailed descriptions for all 13 parameters, including defaults, ranges, and constraints. The description adds only a general note that parameters are optional with sensible defaults, which is already reflected in the schema. Therefore, it meets the baseline for high schema coverage without adding significant extra 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 tool's function ('Generate a video from an image using LTX-Video (local model)') with a specific verb, resource, and model. It distinguishes itself from cloud-based siblings by explicitly directing users to sora_video_generate or run_api_node() for cloud-based I2V, though it doesn't mention other local alternatives like wan_image_to_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool (local LTX-Video) versus alternatives (cloud-based I2V via sora_video_generate or run_api_node), and notes that only prompt and input_image are required. This provides clear usage context, though it could mention other local 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 conveys the core blocking behavior (wait) and return of results. It doesn't detail failure or timeout edge cases, but the timeout parameter description in the schema adds relevant context, so transparency is solid 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?
Two sentences with the main purpose front-loaded and no unnecessary words. The typo 'all of all of them' is minor and doesn't impair clarity.
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 only 2 parameters and an output schema exists, so the description doesn't need to explain return values. It covers the main use case and parallel execution benefit, though it omits potential partial-failure behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions the queue_only=true workflow, linking to the prompt_ids concept, but doesn't add additional syntax or format details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Wait for multiple queued jobs to complete and return all results.' It clearly distinguishes from siblings like get_job_status by emphasizing 'multiple' and 'queue_only=true' 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 clear usage context: 'Use this after queueing multiple jobs with queue_only=true to wait for all of them at once.' This is a precise when-to-use instruction, though it doesn't explicitly mention alternatives like get_job_status for single jobs.
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 local model execution, auto-detection of the Wan model/encoder, and default-driven parameter behavior. However, it omits other behavioral aspects such as output handling, resource requirements, or potential side effects, though the output schema may cover return values.
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 with no wasted words. It front-loads the primary purpose and then gives a concise, useful note about optionality and auto-detection. Every sentence contributes value.
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 15 parameters and a schema covering all parameter descriptions and defaults, the description is sufficiently complete. It covers the model variant, local execution, and auto-detection behavior. It does not explicitly discuss when to prefer this over generic image_to_video, but the tool name and sibling list provide reasonable context.
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?
Since the schema has 100% coverage with default values and descriptions, the baseline is 3. The description adds meaningful semantic context by explicitly stating that only prompt and input_image are required and that clip_name/diffusion_model auto-detect when left empty, going beyond what the schema individually states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Generate video from an image using Wan 2.2 (local model).' This clearly identifies what the tool does and distinguishes it from sibling tools like wan_text_to_video and generic image_to_video by specifying the input type and model variant.
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 states a clear use case ('from an image') and identifies the model (Wan 2.2 local). It also provides practical guidance about optional parameters and auto-detection. However, it does not explicitly name alternatives or exclusion conditions, so it stops short of full 5.
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 describes the return content (running and pending items) but does not disclose any side effects, auth requirements, or rate limits. For a simple read-only getter, this is adequate but not rich. No behavioral traits beyond the obvious are revealed, so a 3 is appropriate.
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: 'Get the current ComfyUI queue with running and pending items.' Every word adds value, and there is no redundant filler. It is concise without being under-specified.
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 that the tool has no parameters and an output schema exists, the description need not explain return values (per rules). The description fully covers what the tool does, and the output schema will handle the return structure. There are no missing pieces for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is nothing to explain. According to the rubric, the baseline for 0 parameters is 4. The description adds no parameter info (there is none needed), which is acceptable. No points lost for missing 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 clearly states the verb 'Get' and the resource 'current ComfyUI queue', and further specifies 'running and pending items'. This distinguishes it from sibling tools like clear_queue (which deletes) and get_job_status (which targets a single job), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for viewing the queue's current state (running and pending). It does not explicitly mention alternatives or exclusions, but the context is clear enough that an agent would know when to use it over siblings like get_history or get_job_status. Lack of explicit 'when not to use' guidance prevents 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?
With no annotations, the description carries the full burden of disclosing behavior. It clearly indicates a read-only 'get' operation and specifies the included data categories, which is sufficient for a simple stats tool. It does not mention failure modes or prerequisites, but these are less critical given the tool's simplicity.
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 immediately states the action and resource, with no redundant wording or filler. It is appropriately concise.
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 zero parameters and an output schema that defines the return structure, the description fully specifies the tool's purpose and behavior. 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 score of 4 applies. There is no parameter confusion or need for additional description.
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 'get' with a clear resource 'ComfyUI system information' and enumerates key data categories (OS, RAM, VRAM, device info), making its purpose unambiguous and distinct from sibling tools like get_queue or get_history.
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 on when to use this tool versus alternatives is provided. The intended use is implied by the simple read-only nature of the tool, but there is no mention of alternatives or contexts where it should not be used.
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 that the tool returns a dict with 'samplers' and 'schedulers' lists, which is sufficient for a read-only list operation. No side effects or permissions are mentioned, but none are expected for this simple list 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 exactly two sentences: one for the action and one for the return format. It is free of unnecessary words and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is extremely simple—no parameters, no complex behavior, and an output schema exists. The description fully covers what the agent needs to know: what it lists and the shape of the result. Nothing further is required.
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 0 parameters, and the input schema is empty. Per the rubric, 0 parameters yields a baseline of 4, and the description does not need to elaborate on parameter semantics that do not exist.
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 lists all available sampler algorithms and noise schedulers, using a specific verb and resource. It distinguishes from sibling list tools like list_models and list_files by naming the exact domain.
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 available samplers/schedulers but provides no explicit when-to-use or alternative context. Since it is a distinct listing tool, the purpose is obvious, but there is no guidance on when not to use it or when to prefer a different tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: auto-insertion of loader and save nodes, and auto-generation of LoadImage/LoadVideo/LoadAudio for file inputs. It doesn't cover error handling or permissions, but the disclosed behavior is substantial and goes beyond a simple 'run' statement.
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 concise and well-structured: first sentence gives purpose, second provides workflow, third gives a concrete file-input example. Every sentence adds useful information without redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, generic node execution), the description covers the essential workflow, file input handling, and timing (timeout, queue_only). It doesn't explicitly mention output retrieval, but the presence of an output schema and sibling tools like get_result_images mitigates this. It's complete enough for a generic runner.
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 baseline is 3. The description adds extra value by explaining how file inputs are handled (pass filename string, auto-insert load node) and by referencing get_node_schema() for input details. This pushes it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs any ComfyUI node in a single call, with the specific action of building a minimal workflow and auto-inserting loader/save nodes. This distinguishes it from specialized sibling tools like text_to_image or sora_video_generate, making its generic-purpose role evident.
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 an explicit workflow: discover nodes with list_api_nodes() or search_nodes(), check inputs with get_node_schema(), then run. It clearly implies use for arbitrary/uncovered nodes, though it doesn't explicitly state when to prefer specialized tools or list exclusions. The workflow guidance is strong enough to earn a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool does not execute the workflow and details four specific checks (node class_types exist, required inputs connected, connection type compatibility, output node exists). This is rich, specific behavioral transparency beyond what annotations would typically provide.
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 highly concise: one sentence for the primary purpose and a compact bullet-style list of checks. Every word earns its place, no redundancy or filler. It is perfectly structured, front-loading the main action.
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 single-parameter validation tool with an output schema. The description covers the tool's purpose, non-execution behavior, and specific checks, which is complete for an agent to select and invoke it correctly. The output schema handles return value details, and no further context is required.
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% description coverage for the single parameter (workflow_id: 'The workflow to validate.'). The description adds no additional semantic meaning beyond the schema, so the baseline of 3 applies. No further parameter context 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 tool's function with a specific verb and resource: 'Validate a workflow for correctness.' It distinguishes itself from execution tools by adding 'without executing it,' and enumerates the exact validation checks performed (node class_types, input connections, type compatibility, output node). This makes the purpose unambiguous and easily distinguishable from siblings like execute_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?
The phrase 'without executing it' implies the tool is for pre-execution validation, providing clear context for when it should be used. However, it does not explicitly name alternatives (e.g., 'use execute_workflow to run it') or list exclusions, so it falls short of a perfect 5. The context is clear enough for an agent to decide appropriately.
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/halbert04/comfyui-mcp/badges/card.svg)](https://glama.ai/mcp/servers/halbert04/comfyui-mcp)

Score Badge

Copy to your README.md:

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

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