ComfyUI MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between execute_workflow, run_workflow, and generate_image that could cause confusion. For example, generate_image is described as a simplified interface, but its relationship to the other execution tools isn't entirely clear from the descriptions alone. However, the majority of tools target specific operations like workflow management, node handling, and system monitoring.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, such as add_node, cancel_current, clear_queue, and get_history. There are no deviations in naming conventions, making it easy to predict what each tool does based on its name. This consistency enhances usability for agents.
Tool Count3/5
With 31 tools, the count is borderline high for a single server, potentially overwhelming for agents. While ComfyUI is a complex system with many operations, some tools like generate_workflow_name and get_system_stats might be considered non-essential, contributing to a slightly bloated interface. A more focused set could improve coherence.
Completeness5/5
The tool surface comprehensively covers the ComfyUI domain, including workflow creation, modification, execution, monitoring, and system management. It supports full CRUD-like operations for workflows and nodes, provides templates and history, and handles edge cases like validation and conversion. No obvious gaps are present for the stated purpose.
Average 3.6/5 across 31 of 31 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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool loads a workflow 'for inspection or modification' and returns a 'workflow dict that can be modified and executed', which hints at mutability and potential side effects. However, it lacks details on permissions, error handling, or whether loading affects system state (e.g., locks the file). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with three sentences that efficiently convey purpose, parameters, and return value. There's no wasted text, and key information is front-loaded. However, the use of a code block for Args/Returns slightly disrupts flow, though it remains readable.
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 moderate complexity (1 parameter, no output schema, no annotations), the description is partially complete. It covers the basic purpose and return value but lacks usage guidelines, behavioral details, and output specifics. Without annotations or an output schema, more context on what the 'workflow dict' contains or how to use it would be beneficial for the agent.
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 description adds minimal value beyond the input schema. It repeats the parameter name and provides an example ('my-workflow.json'), but the schema already has 100% coverage with a clear description ('Workflow filename'). Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Load a workflow file for inspection or modification.' It specifies the verb ('load') and resource ('workflow file'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_workflow_template' or 'list_workflows', which might have overlapping functions.
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 doesn't mention prerequisites, when not to use it, or compare it to siblings like 'get_workflow_template' or 'list_workflows'. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.
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 mentions that the tool 'Returns the generated image or error message,' which adds some behavioral context about outputs. However, it lacks details on execution behavior (e.g., synchronous/asynchronous, side effects, permissions, or error handling), which is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The Args and Returns sections are structured clearly, though the formatting with indentation could be slightly improved for readability. Every sentence adds value without redundancy.
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 complexity (3 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose and parameters well but lacks behavioral details (e.g., execution mode, error conditions) and doesn't fully compensate for the absence of annotations and output schema, leaving gaps for an execution 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 documents all parameters. The description adds value by providing examples (e.g., 'flux-dev.json' for workflow_name, '{"6": {"text": "new prompt"}}' for inputs) and clarifying that output_node_id 'uses default if not set,' which enhances understanding beyond the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Execute') and resource ('a saved workflow file'), making the purpose evident. It distinguishes from siblings like 'create_workflow' or 'load_workflow' by focusing on execution, but could be more specific about what 'execute' entails compared to similar tools like 'execute_workflow' or 'submit_workflow'.
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. With siblings like 'execute_workflow' and 'submit_workflow', the description lacks context on differences, prerequisites, or exclusions, leaving the agent to infer usage from tool names 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 provided, so the description carries the full burden. It mentions that results are 'sorted by relevance', which adds some behavioral context. However, it lacks details on permissions, rate limits, pagination, or error handling, which are important for a search operation with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the core purpose, includes an 'Args' section for parameters, and ends with return behavior. However, the formatting with indentation and line breaks could be slightly cleaner for optimal readability.
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 moderate complexity (search operation with one parameter), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and parameter semantics but lacks details on output format, error cases, or integration with sibling tools, leaving gaps in completeness.
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 documents the 'query' parameter. The description adds that the query searches 'name, category, description', which provides additional semantic context beyond the schema's generic 'Search query'. This justifies a baseline score of 3, as the description adds some value but the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for nodes by name, category, or description.' It specifies the verb (search) and resource (nodes), and mentions the searchable fields. However, it doesn't explicitly differentiate from sibling tools like 'list_nodes' or 'get_node_info', which would require a 5.
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 doesn't mention sibling tools like 'list_nodes' (which might list all nodes without search) or 'get_node_info' (which might retrieve details for a specific node), leaving the agent to infer 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 provided, the description carries the full burden of behavioral disclosure. It states the tool modifies a workflow dict and returns it, implying mutation, but doesn't cover critical aspects like whether changes are reversible, permission requirements, error handling, or side effects. This leaves significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a structured Args section that efficiently lists parameters. It avoids unnecessary fluff, though the parameter details could be more integrated into the main text rather than a separate block.
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 no annotations, no output schema, and a mutation tool with nested objects, the description is incomplete. It lacks details on return format beyond 'modified workflow dict', error conditions, or how the update affects the workflow state, making it inadequate for safe and effective 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 schema already documents all parameters thoroughly. The description adds minimal value by repeating parameter names and noting JSON string usage for complex values, which is already hinted in the schema. Baseline 3 is appropriate as 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 action ('Update') and target ('a specific input on a node'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'add_node' or 'remove_node' in terms of scope, though the specificity of updating an input rather than the node itself provides some implicit distinction.
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 like 'add_node' or 'remove_node', nor does it mention prerequisites such as needing an existing workflow or node. It lacks explicit context for usage decisions.
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 mentions validation and returns issues, but lacks details on error handling, performance (e.g., speed or limits), side effects, or what constitutes a valid workflow. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear purpose statement followed by Args and Returns sections. It avoids unnecessary words, but the Args section slightly repeats schema information without adding new insights, keeping it from a perfect score.
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 no annotations, no output schema, and a single parameter with nested objects, the description is incomplete. It doesn't explain what a 'validation result' includes (e.g., error messages, success status) or the structure of the 'workflow dict,' leaving gaps for the agent to infer behavior and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'workflow' documented as 'Workflow to validate.' The description adds minimal value by restating this in the Args section without extra context like format examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting, but no additional semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Validate a workflow structure.' It specifies the verb ('validate') and resource ('workflow structure'), making it easy to understand. However, it doesn't differentiate from sibling tools like 'run_workflow' or 'execute_workflow' that might involve validation implicitly, so it falls short of 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., before execution), exclusions, or how it differs from siblings like 'run_workflow' or 'execute_workflow' that might handle validation internally. This lack of context leaves the agent guessing about optimal usage 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 of behavioral disclosure. It states the tool deletes or clears items, implying a destructive mutation, but doesn't cover critical aspects like permissions needed, whether deletions are permanent, error handling, or rate limits. For a destructive tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with a clear purpose statement, includes an Args section with parameter details, and ends with a usage tip. Each sentence adds value without redundancy. It could be slightly more front-loaded by integrating the usage tip earlier, but overall it's efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive mutation with no output schema) and lack of annotations, the description is incomplete. It doesn't explain what happens after clearing (e.g., confirmation, error messages), potential side effects, or how it interacts with sibling tools like 'cancel_current'. For a queue management tool, more context on behavior and outcomes is needed.
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 description adds minimal semantics beyond the input schema: it explains that 'delete_ids' is optional and that omitting it clears the entire queue. Since schema description coverage is 100%, the schema already documents the parameter well, so the description provides only marginal additional value, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Clear the queue or delete specific items.' It specifies the verb ('clear'/'delete') and resource ('queue'/'items'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from siblings like 'cancel_current' or 'remove_node', which might have overlapping functions, preventing 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance: 'Use this to remove pending jobs from the queue.' This implies when to use it (for pending jobs) but doesn't specify when NOT to use it or mention alternatives like 'cancel_current' for active jobs. The guidance is helpful but incomplete, lacking explicit exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a workflow dict that can be modified and executed, which adds some behavioral context beyond basic retrieval. However, it lacks details on permissions, error handling, rate limits, or whether this is a read-only operation (implied but not stated). For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by structured parameter details and return information. Every sentence adds value, with no wasted words. Minor improvement could be made by integrating the return statement more seamlessly.
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 low complexity (1 parameter, no nested objects) and 100% schema coverage, the description is moderately complete. It covers purpose, parameters, and return value. However, with no output schema and no annotations, it should ideally include more behavioral details (e.g., read-only nature, error cases) to fully compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the semantics of 'template_name' options: it lists the three possible values ('empty', 'fal-flux-dev', 'fal-flux-schnell') and provides brief explanations for two of them (e.g., 'higher quality' vs. 'faster'), which enhances understanding beyond the schema's enum-like listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a pre-built workflow template.' It specifies the verb ('Get') and resource ('workflow template'), and distinguishes it from siblings like 'create_workflow' or 'list_templates' by focusing on retrieval of specific templates rather than creation or listing. However, it doesn't explicitly differentiate from 'list_templates' in terms of granularity (single vs. multiple).
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 doesn't mention when to choose this over 'list_templates' (e.g., for detailed template retrieval vs. listing names) or 'create_workflow' (e.g., for starting from a template vs. from scratch). Usage is implied through the description but not explicitly stated.
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 mentions that the tool 'Returns the generated image or error message', which adds some behavioral context about outputs. However, it lacks details on permissions, rate limits, side effects (e.g., queue impact), or error handling. For a tool that executes workflows with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the purpose, lists args and returns, and ends with usage guidance. Each sentence adds value, with no wasted words. However, it could be slightly more front-loaded by emphasizing the 'programmatically built workflows' aspect earlier.
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 complexity (executing workflows with nested objects), no annotations, and no output schema, the description is moderately complete. It covers the basic purpose, parameters, and return values, but lacks details on behavioral aspects like error conditions, performance, or integration with sibling tools. It's adequate but has clear gaps for a tool of this nature.
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 documents both parameters ('workflow' and 'output_node_id') with descriptions. The description adds minimal value by specifying 'workflow dict in ComfyUI API format' and 'Node ID that outputs the final image', which slightly clarifies formats but doesn't provide deep semantic insights beyond the schema. Baseline 3 is appropriate as 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 purpose: 'Execute an arbitrary workflow dict' with the verb 'Execute' and resource 'workflow dict'. It distinguishes from siblings like 'run_workflow' and 'submit_workflow' by specifying 'programmatically built workflows', though the distinction could be more explicit. The purpose is specific but not fully differentiated from all similar tools.
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 some usage guidance: 'Use this for programmatically built workflows.' This implies when to use it (for programmatic workflows) but doesn't explicitly state when not to use it or name alternatives like 'run_workflow' or 'submit_workflow'. The guidance is present but incomplete, leaving room for ambiguity.
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 mentions 'Returns status information including completion state', which adds some behavioral context about the output. However, it lacks details on error handling, rate limits, authentication needs, or whether this is a read-only operation, leaving significant gaps for a tool that queries system state.
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 front-loaded with the main purpose in the first sentence, followed by structured Args and Returns sections. It's efficient with no wasted words, though the formatting could be slightly cleaner for better readability.
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 no annotations and no output schema, the description provides basic purpose and parameter context but is incomplete. It doesn't detail the structure of the returned status information, error cases, or how it integrates with sibling tools like 'submit_workflow', leaving the agent with insufficient guidance for robust 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%, with the parameter 'prompt_id' documented as 'Prompt ID to check'. The description adds minimal value by specifying 'The prompt ID from submit_workflow()', which provides a source context but doesn't elaborate on format or validation beyond what the schema already covers.
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 verb 'Get' and resource 'status of a submitted prompt', making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'get_queue_status' or 'get_history', which might also provide status information in different contexts.
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 by referencing 'prompt_id from submit_workflow()', suggesting it should be used after submission to check completion. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_queue_status' or 'get_history', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool returns ('list of embedding names that can be used in prompts'), which is helpful, but lacks critical details such as whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or how the list is formatted (e.g., pagination, sorting). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 extremely concise and well-structured with two brief sentences that directly address purpose and output. Every word earns its place, with no redundant information or fluff. It's front-loaded with the core purpose followed by additional context about the return value.
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 (0 parameters, no annotations, no output schema), the description is minimally adequate. It explains what the tool does and what it returns, which covers the basics for a listing tool. However, without annotations or output schema, it should ideally provide more behavioral context (e.g., read-only nature, any limitations) to be fully complete for agent use.
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 with 100% schema description coverage, so the schema fully documents the lack of inputs. The description appropriately doesn't discuss parameters, which is correct for a parameterless tool. It adds value by explaining the return semantics ('list of embedding names that can be used in prompts'), compensating for the lack of output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('available text embeddings'), making it immediately understandable. It distinguishes itself from siblings by focusing on embeddings rather than workflows, nodes, or other resources. However, it doesn't explicitly differentiate from potential similar tools like 'list_models' or 'list_extensions' beyond the resource name.
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 doesn't mention prerequisites, context for usage, or compare it to sibling tools like 'list_models' or 'list_extensions'. The agent must infer usage based solely on the tool name and description without explicit direction.
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 burden. It mentions the tool 'interrupts' and 'cancels', implying a destructive action, but doesn't specify permissions needed, whether cancellation is reversible, or what happens to partial results. For a mutation tool with zero annotation coverage, this leaves significant behavioral 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 highly concise and well-structured: a clear purpose statement, parameter explanation, and usage note in three brief lines. Every sentence adds value with no redundancy or fluff, making it easy to scan and understand.
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 1 parameter with full schema coverage and no output schema, the description is moderately complete. It covers the basic purpose and parameter default behavior but lacks details on permissions, side effects, or error handling. For a destructive tool without annotations, it should provide more behavioral context to be fully adequate.
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 documents the single parameter 'prompt_id'. The description adds marginal value by clarifying the default behavior: 'If not provided, cancels all running jobs.' This provides context beyond the schema's description of 'Specific prompt ID to cancel', but doesn't add syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Interrupt current generation' with a specific verb ('interrupt') and resource ('current generation'). It distinguishes from siblings like 'clear_queue' by focusing on active jobs rather than queued ones. However, it doesn't explicitly contrast with all relevant siblings like 'submit_workflow' or 'run_workflow'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: 'Use this to stop a long-running generation' implies when to use it. However, it doesn't explicitly state when NOT to use it (e.g., for queued vs. running jobs) or name specific alternatives among siblings like 'clear_queue' for queued items. The guidance is helpful but incomplete.
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 adequately describes the core behavior (retrieving history entries with outputs and status) and implies read-only operation through 'Get' and 'see past generations.' However, it lacks details about pagination, rate limits, authentication requirements, or what happens when no history exists - gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three brief sentences that each serve a purpose: stating the tool's purpose, documenting the parameter, and providing usage guidance. It's front-loaded with the core purpose first. The only minor inefficiency is repeating parameter information already in the schema.
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 single-parameter read operation with no output schema, the description provides adequate but minimal coverage. It explains what the tool does and what it returns, but lacks details about the return format structure, error conditions, or how 'recent' is defined. With no annotations and no output schema, more behavioral context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the 'limit' parameter with range, default, and description. The description repeats this information in the Args section but adds no additional semantic context beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with 'Get recent generation history' - a specific verb ('Get') and resource ('generation history'). It distinguishes itself from siblings by focusing on historical data retrieval rather than current operations (like get_queue_status) or workflow management tools. However, it doesn't explicitly contrast with all possible siblings like get_system_stats.
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 implied usage context with 'Use this to see past generations and their results,' suggesting it's for reviewing completed jobs. However, it doesn't explicitly state when to use this versus alternatives like get_queue_status (for pending jobs) or get_prompt_status (for specific job status), nor does it mention any exclusions or prerequisites.
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 mentions the return value ('list of template names') but doesn't cover other behavioral aspects such as permissions needed, rate limits, error handling, or whether it's a read-only operation. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of two brief sentences that directly address the tool's purpose and output. There is no wasted language, and the information is front-loaded, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It explains the purpose and output, but lacks details on behavioral traits like error handling or usage context. For a basic list tool, it meets minimum requirements but could be more informative to fully guide an agent.
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 schema description coverage is 100%, so there's no need for parameter details in the description. The description appropriately focuses on the tool's purpose and output without redundant parameter information, aligning with the baseline expectation for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List available workflow templates.' It specifies the verb ('List') and resource ('workflow templates'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_workflows' or 'list_nodes', which is why it doesn't score a 5.
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 by stating 'Returns list of template names for get_workflow_template()', suggesting this tool is used to retrieve template names for another tool. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'list_workflows' or 'get_workflow_template' directly, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns specific information (input, output, category, description), which is useful behavioral context. However, it doesn't mention error handling (e.g., what happens if the node doesn't exist), performance aspects (e.g., speed or caching), or authentication needs, leaving gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose in the first sentence. The bullet points efficiently list return values, and the final sentence provides usage context. There's minimal waste, though the bullet points could be slightly more concise, and the structure is clear but not perfectly optimized.
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 complexity (simple read operation with one parameter) and lack of annotations and output schema, the description is somewhat complete but has gaps. It explains what information is returned, which helps, but doesn't cover error cases, response format details, or how it integrates with sibling tools like 'add_node' or 'update_node_input,' making it adequate but not fully comprehensive.
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 description coverage is 100%, so the schema already documents the parameter 'node_name' with a description. The description adds value by providing an example ('RemoteCheckpointLoader_fal') and clarifying that it's the 'Node class name,' which enhances understanding beyond the schema's 'Exact node class name.' This compensates well, though it doesn't detail format constraints beyond the example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed info about a node'), and it distinguishes this from siblings like 'list_nodes' (which likely lists nodes without details) or 'search_nodes' (which searches for nodes). However, it doesn't explicitly contrast with all siblings, such as 'get_history' or 'get_system_stats', which also retrieve information but about different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Use this to understand how to configure a node in a workflow,' which suggests it's for learning about node configuration. However, it doesn't explicitly state when to use this tool versus alternatives like 'list_nodes' (for overview) or 'search_nodes' (for finding nodes), and it lacks guidance on prerequisites or exclusions, such as whether the node must exist or be available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it returns 'the image if available, or error message,' which adds useful behavioral context about potential outcomes. However, it doesn't cover other traits like error conditions (e.g., invalid IDs), performance aspects, or authentication needs, leaving gaps for a tool with no annotation support.
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 front-loaded with the core purpose in the first sentence, followed by concise parameter explanations and return behavior. Every sentence earns its place without waste, and the structure is clear and efficient for a tool with two parameters.
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 no annotations, no output schema, and 100% schema coverage, the description is moderately complete. It covers the basic purpose and parameters but lacks details on error handling, image format, or dependencies (e.g., requiring a completed prompt). For a retrieval tool with no structured output info, it should do more to compensate.
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 documents both parameters ('prompt_id' and 'output_node_id'). The description adds minimal value by linking 'prompt_id' to 'submit_workflow()' and clarifying 'output_node_id' as the 'Node ID that produced the image,' but this is redundant with the schema. Baseline 3 is appropriate as 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 purpose: 'Get the result image from a completed prompt.' It specifies the verb ('Get') and resource ('result image'), and distinguishes it from siblings like 'generate_image' (which creates images) or 'get_prompt_status' (which checks status). However, it doesn't explicitly contrast with all siblings, such as 'get_history' which might also retrieve results.
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 by referencing 'a completed prompt' and 'prompt ID from submit_workflow()', suggesting it should be used after workflow submission. However, it lacks explicit guidance on when not to use it (e.g., for non-image outputs) or clear alternatives among siblings like 'get_prompt_status' for checking completion first.
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 states the tool creates an empty structure and returns an empty dict, which covers the basic operation and output. However, it lacks details on potential side effects, error conditions, or performance considerations, leaving gaps in 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 extremely concise with two sentences that directly state the action and the intended use of the output. Every word serves a purpose, and it's front-loaded with the core functionality, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but minimal. It explains what the tool does and hints at usage, but for a creation tool, it could benefit from more context on integration with sibling tools or error handling, though the lack of complexity keeps it from being incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose and output without redundant parameter details, earning a baseline score above 3 due to the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'empty workflow structure', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'load_workflow' or 'get_workflow_template', which also involve workflow initialization or retrieval.
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 by mentioning that the result can be populated with 'add_node()', suggesting it's for building workflows from scratch. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'load_workflow' or 'get_workflow_template', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the return value ('list of valid folder names') and its purpose for 'list_models()', which adds useful context. However, it lacks details on behavioral traits such as rate limits, error handling, or whether it's a read-only operation (though implied by 'List'), leaving some gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence states the purpose, and the second adds context about the return value. Every sentence earns its place with no wasted words, making it efficient and well-structured for quick understanding.
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 (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains the purpose and return value's use for 'list_models()', but doesn't detail the return format (e.g., list structure or data types) or potential errors. For a no-param tool, this is minimally viable but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to add parameter details, so it naturally compensates by focusing on output semantics. A baseline of 4 is appropriate as the description adds value without redundancy, though it doesn't fully explain the return format (e.g., structure of the list).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List available model folder types.' This is a specific verb ('List') and resource ('model folder types'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_models' or 'list_nodes', which prevents 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the return value helps 'list_models()', suggesting it's a prerequisite or helper for that tool. However, it doesn't provide explicit guidance on when to use this vs. alternatives like 'list_models' or 'list_nodes', nor does it specify exclusions or prerequisites beyond the implied relationship.
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 key behavioral traits: the tool submits asynchronously and returns a prompt_id for tracking, which is essential context. However, it lacks details on error handling, rate limits, permissions, or what constitutes a valid 'workflow dict', 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 front-loaded with the core purpose, followed by efficient bullet points for args and returns. Every sentence earns its place by providing essential information without redundancy, making it highly readable and to-the-point.
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 complexity (asynchronous submission with tracking) and no annotations or output schema, the description covers the basic flow but lacks details on error cases, workflow validation, or response format beyond prompt_id. It's adequate for minimal use but incomplete for robust agent operation.
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 documents the single parameter 'workflow' as an object. The description adds minimal value by restating 'Workflow dict to execute' without explaining the structure or requirements. Baseline 3 is appropriate as 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 action ('submit a workflow') and distinguishes it from waiting for completion, which differentiates it from siblings like 'execute_workflow' or 'run_workflow' that might imply synchronous execution. However, it doesn't explicitly contrast with all similar tools (e.g., 'run_workflow'), leaving some ambiguity.
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 this tool ('without waiting for completion') and explicitly names alternative tools for checking status ('get_history() or get_prompt_status()'). It doesn't specify when NOT to use it or compare with all siblings like 'execute_workflow', but the guidance is practical and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a 'simplified interface' and mentions configuration requirements (COMFY_WORKFLOW_JSON_FILE, etc.), which adds useful context. However, it lacks details on behavioral traits like error handling, rate limits, or output format (e.g., image type, size). The description doesn't contradict annotations (none exist), but it's incomplete for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It front-loads the main purpose, follows with usage context and alternatives, and ends with parameter details. Each sentence earns its place, though the Args section is somewhat redundant given the schema. It's concise but could be slightly tighter by integrating the parameter note more seamlessly.
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 complexity (image generation with configuration dependencies), no annotations, and no output schema, the description is moderately complete. It covers purpose, usage guidelines, and hints at configuration needs, but lacks details on output (e.g., image format, handling), error cases, or performance expectations. For a tool with no structured data support, it should do more to compensate.
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 the 'prompt' parameter well-documented. The description adds minimal value beyond the schema, only restating 'prompt: Text description of the image to generate' in the Args section. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate an image using the default workflow.' It specifies the verb ('generate') and resource ('image'), though it doesn't explicitly distinguish it from sibling tools like 'run_workflow' or 'execute_workflow' beyond mentioning them as alternatives. The purpose is clear but lacks explicit 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. alternatives: 'This is a simplified interface for quick image generation' and 'For more control, use run_workflow() or execute_workflow().' It clearly states the intended context (simplified, quick) and names specific alternatives, making it easy for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns 'a sorted list of node class names,' which is useful behavioral context not in the schema. However, it does not mention potential limitations like rate limits, authentication needs, or whether the list is paginated/complete, leaving gaps for a read 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 appropriately sized and front-loaded, starting with the core purpose. The Args and Returns sections are structured but slightly verbose; every sentence earns its place by clarifying usage, though it could be more streamlined (e.g., integrating the 'Use this' sentence into the opening).
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 low complexity (read-only list operation), 2 parameters with full schema coverage, and no output schema, the description is adequate but has gaps. It explains the return format ('sorted list of node class names') but does not cover behavioral aspects like error handling or performance, which could be useful for an agent. It meets minimum viability but lacks depth.
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 documents both parameters ('filter' and 'category') with descriptions. The description adds minimal value by restating the parameters in the Args section without providing additional meaning beyond the schema, such as examples of categories or how filtering interacts. Baseline 3 is appropriate as 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 specific action ('List available ComfyUI nodes') and resource ('nodes'), distinguishing it from siblings like 'search_nodes' (which likely has different filtering capabilities) and 'get_node_info' (which focuses on individual node details). It explicitly mentions the purpose is 'to discover available nodes for workflow building,' making the intent 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 provides clear context on when to use this tool ('to discover available nodes for workflow building'), but it does not explicitly state when not to use it or name alternatives like 'search_nodes' (which might offer more advanced filtering). The guidance is helpful but lacks explicit exclusions or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explicitly warning about the behavioral limitation ('doesn't update connections from other nodes'). This discloses a critical trait that affects workflow integrity. However, it doesn't mention other behavioral aspects like error conditions, permissions needed, or what happens to the modified workflow object.
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 appropriately sized with three sentences that each serve a purpose: stating the action, documenting parameters, and providing a critical warning. It's front-loaded with the core purpose. The only minor inefficiency is repeating parameter descriptions that already exist in the schema.
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 mutation tool with no annotations and no output schema, the description provides adequate but incomplete context. The warning about connection updates is valuable, but it doesn't explain what the tool returns, how errors are handled, or the full implications of modifying the workflow dict. Given the complexity and lack of structured safety information, more behavioral disclosure would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters completely. The description repeats the parameter descriptions verbatim from the schema ('Workflow dict to modify', 'ID of node to remove'), adding no additional semantic meaning beyond what's already in the structured fields. Baseline 3 is appropriate when schema does all the work.
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 ('Remove a node') and resource ('from a workflow'), distinguishing it from sibling tools like 'add_node' or 'update_node_input'. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
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 context through the warning about not updating connections, suggesting this tool should be used when removing a node without maintaining workflow connectivity. However, it doesn't explicitly state when to use this versus alternatives like 'update_node_input' or 'clear_queue', nor does it mention prerequisites or integration with other workflow management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by detailing the conversion process: assigns integer IDs, places nodes in grid layout, creates visual links from input connections, and sets node sizes based on type. It doesn't mention error handling, performance characteristics, or authentication needs, but provides substantial 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?
Well-structured with clear sections (Args, Returns, The conversion) and front-loaded purpose statement. The bullet points under conversion are helpful but slightly verbose. Every sentence adds value, though some information in Returns could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter conversion tool with no annotations and no output schema, the description provides good completeness: clear purpose, parameter context, detailed conversion behavior, and output format explanation. It could benefit from error cases or performance notes but covers the essential context well.
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 one parameter clearly documented. The description adds minimal value beyond the schema by specifying the workflow should be in 'API format (flat dict with class_type/inputs)', which slightly elaborates on the schema's 'Workflow in API format'. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts an API format workflow to UI/Litegraph format, specifying both the input (flat dict with class_type/inputs) and output (UI format with node positions, visual links, metadata). It distinguishes from siblings like create_workflow or load_workflow by focusing on format conversion rather than creation or loading.
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 needing UI-compatible workflow format for display/editing in ComfyUI editor, but doesn't explicitly state when to use this vs alternatives like validate_workflow or run_workflow. No exclusions or specific prerequisites are mentioned.
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 the tool modifies the workflow (mutation behavior) and returns the modified dict, but it lacks details on permissions, error handling, or side effects. It adds basic context but misses deeper behavioral traits like what happens on invalid inputs or if the node_id already exists.
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 appropriately sized and front-loaded with the core purpose. The examples are informative but slightly verbose; every sentence earns its place by illustrating usage, though it could be more streamlined without losing clarity.
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 complexity (4 parameters, nested objects, no output schema, and no annotations), the description is moderately complete. It covers the basics and includes examples, but it lacks details on error conditions, return format beyond 'modified workflow dict', and integration with sibling tools like 'validate_workflow'. For a mutation tool with rich context, it should do more to guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the 'inputs' parameter with examples (e.g., using connections with source_node_id and output_index), clarifying semantics beyond the schema's generic 'Node inputs' description. However, it does not elaborate on 'workflow' or 'node_type' beyond what the schema 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 clearly states the specific action ('Add a node to a workflow') and distinguishes it from siblings like 'remove_node' and 'update_node_input'. It specifies the resource (workflow) and verb (add) with precision, making its purpose immediately apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage through examples and references to sibling tools (e.g., 'use list_nodes() to find' node types), but it does not explicitly state when NOT to use this tool or name alternatives for similar operations. The guidance is helpful but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what the tool returns (system information) and its purpose (health verification), but lacks details on behavioral traits such as rate limits, authentication requirements, or whether it's a read-only operation (though implied by 'get'). This is adequate but has gaps for a tool with no annotations.
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 well-structured and front-loaded with the main purpose, followed by bullet points for returns and a usage guideline. Every sentence adds value without redundancy, and it is 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?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is mostly complete: it explains what the tool does, what it returns, and when to use it. However, it lacks details on output format or error handling, which could be useful for an agent, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention any parameters, which is appropriate. A baseline of 4 is applied since it correctly omits unnecessary parameter details, but it doesn't add extra value 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 specific action ('Get ComfyUI server health') and resource ('system information'), distinguishing it from sibling tools that focus on workflows, nodes, images, or queues. It explicitly lists what information is returned (versions, memory, device info), making the 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 provides clear context for when to use this tool ('to verify ComfyUI is running and check resource usage'), which is helpful for an agent. However, it does not explicitly state when not to use it or name alternatives (e.g., using get_queue_status for queue-related health checks), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a list of installed extension names, which is useful behavioral context. However, it lacks details on potential limitations (e.g., whether it includes built-in vs. third-party extensions, error handling, or performance characteristics).
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 and well-structured: three brief sentences that each add value—stating the action, describing the return value, and providing usage context. There is no redundant or verbose language, and information is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is largely complete: it explains what the tool does and its purpose. However, without an output schema, it could benefit from more detail on the return format (e.g., list structure, data types) to fully guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and output. A baseline of 4 is applied as it correctly omits unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List loaded ComfyUI extensions') and resource ('extensions'), distinguishing it from siblings like list_models or list_nodes by focusing on extension names/custom node packs. It provides a concrete example ('fal.ai connector') to illustrate the resource type.
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 explicitly states when to use this tool: 'to verify which custom nodes are available.' This provides clear context for its purpose. However, it does not mention when not to use it or name specific alternatives among siblings (e.g., list_nodes for node details vs. list_extensions for extension packs).
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 the tool returns a list of filenames, which is useful behavioral context. However, it doesn't mention potential limitations like pagination, rate limits, or error conditions, leaving gaps for a read 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 front-loaded with the core purpose, followed by structured parameter details and return value. Every sentence adds value without redundancy, and the bulleted list enhances readability 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 read tool with one parameter and no output schema, the description is largely complete—it explains purpose, parameters, and return value. However, without annotations or output schema, it could benefit from more behavioral details like error handling or format specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter, so the baseline is 3. The description adds significant value by expanding the folder options beyond the schema's list (e.g., adding controlnet, upscale_models, clip_vision), providing clearer semantics and usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List available models') and resource ('in a folder'), distinguishing it from sibling tools like list_embeddings or list_model_folders. It provides precise scope by listing folder options, making the 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 implicitly suggests usage when needing to list models in specific folders, with the folder parameter options providing context. However, it lacks explicit guidance on when to use this tool versus alternatives like list_embeddings or list_model_folders, which might overlap in functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool saves files to a specific directory ('workflows directory'), generates random funny names when 'name' is not provided, defaults to 'ui' format, and returns either a path or error message. This covers the core operational behavior well, though it doesn't mention permissions, rate limits, or error specifics.
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 efficiently structured: a clear purpose statement followed by well-organized parameter explanations and return value note. Every sentence adds value without redundancy. The parameter descriptions are appropriately detailed yet concise, and the overall length is optimal for the tool's complexity.
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 (3 parameters with nested objects), no annotations, and no output schema, the description does well: it covers purpose, parameters with semantics, default behaviors, and return types. However, it doesn't mention potential side effects, error conditions beyond 'error message', or how the saved workflow integrates with other tools (e.g., 'execute_workflow'), leaving minor gaps in full 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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: it clarifies that 'workflow' should be 'in API format', specifies that 'name' can include or exclude '.json' extension, explains what 'cosmic-penguin' style names mean, and elaborates on format options ('api' for execution vs 'ui' for editor). This provides valuable semantic understanding that enhances the schema's technical descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Save a workflow') and target ('to the workflows directory'), distinguishing it from sibling tools like 'create_workflow', 'load_workflow', or 'list_workflows'. It specifies the verb+resource combination precisely without being tautological.
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 saving workflows, but provides no explicit guidance on when to use this tool versus alternatives like 'create_workflow' or 'load_workflow'. It mentions default behaviors (e.g., format defaults to 'ui') but doesn't clarify scenarios where one might choose this over other workflow-related 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 discloses that it returns a list of files, which is basic behavioral info. However, it lacks details like error handling, permissions needed, or whether it's read-only (though implied by 'List'), leaving gaps in 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 front-loaded with the core purpose in the first sentence, followed by a clarifying detail and a usage guideline. Every sentence adds value, with no wasted words, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is complete enough for a list operation. It explains what it returns and when to use alternatives. A minor deduction because it could mention format specifics (e.g., JSON structure) or error cases, but overall it's 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?
There are 0 parameters, and schema description coverage is 100%, so the baseline is high. The description adds no parameter info (as none exist), but this is appropriate and doesn't detract from clarity. A 4 reflects that it handles the zero-parameter case well without unnecessary 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 'List' and the resource 'available workflow files', specifying they are 'JSON files in the configured workflows directory'. It distinguishes from siblings like 'run_workflow' by focusing on listing rather than executing.
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 'Use run_workflow() to execute a saved workflow', providing a clear alternative for when not to use this tool. This directly addresses when to use this tool versus a sibling, which is ideal.
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 full burden. It describes the cache-refresh behavior and its effect on list_nodes, but doesn't mention potential side effects like performance impact, whether it's idempotent, or error conditions. It adds useful context but lacks comprehensive 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?
Two sentences with zero waste. First sentence states the core action, second provides essential usage context. Perfectly front-loaded and appropriately sized for a simple 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 zero-parameter tool with no annotations or output schema, the description provides complete enough context about when and why to use it. It could benefit from mentioning what 'refreshing' entails or confirmation of success, but covers the essentials well.
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?
With 0 parameters and 100% schema coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's purpose and usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Refresh') and resource ('node cache'), distinguishing it from siblings like 'list_nodes' or 'add_node'. It explains the tool's purpose is to update the cache after installing new custom nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'after installing new custom nodes to see them in list_nodes()'. This provides clear context and distinguishes it from alternatives like directly calling list_nodes without refreshing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it generates random funny names, returns a slug format (e.g., 'cosmic-penguin'), and has a default parameter value. However, it lacks details on randomness characteristics (e.g., seed, reproducibility) or potential errors, which would elevate the score to 5.
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 front-loaded with the core purpose in the first sentence, followed by parameter details, return format, and usage guidelines in a logical flow. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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 low complexity (one parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, parameters, return format, and usage context. However, it lacks output schema details (e.g., exact structure of the slug), which slightly reduces completeness for a tool with no structured output documentation.
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 description coverage is 100%, so the schema already documents the 'words' parameter fully. The description adds minimal value by restating the parameter range (2-4) and default (2), but it doesn't provide additional semantic context beyond what's in the schema. Since there's only one parameter, the baseline is 4, but it doesn't fully compensate with extra insights.
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 ('generate a random funny workflow name') and distinguishes it from sibling tools like 'create_workflow' or 'save_workflow' by focusing on name generation rather than workflow creation or management. It specifies the resource ('workflow name') and the creative nature ('funny'), making the 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this when saving new workflows for creative naming.' This provides clear context for its application, distinguishing it from other workflow-related tools like 'create_workflow' or 'save_workflow' that handle different aspects of workflow management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (queue status with specific fields) and implies it's a read-only operation by using 'Get' and 'check,' though it doesn't explicitly state permissions, rate limits, or side effects. It adds useful context about the return structure, which is valuable given the lack of annotations.
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 well-structured and front-loaded with the main purpose, followed by a clear breakdown of return values and usage guidance. Every sentence earns its place by adding value—no wasted words or redundancy. It's appropriately sized for a tool with no parameters and clear output details.
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 (simple read operation with 0 parameters) and lack of annotations/output schema, the description is quite complete: it explains the purpose, return structure, and usage. However, it doesn't cover potential edge cases like error handling or data freshness, which could be useful for an agent. Still, it provides sufficient context for effective use.
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 with 100% schema description coverage, so the schema already fully documents the inputs. The description doesn't need to add parameter details, but it does mention the context of 'workflows' which aligns with the tool's purpose. Since there are no parameters, a baseline of 4 is appropriate as the description compensates by explaining the output semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get current queue') and resource ('running and pending jobs'), distinguishing it from siblings like get_history, get_system_stats, or get_prompt_status which focus on different aspects of the system. It precisely defines what the tool retrieves without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use this to check if workflows are executing or queued,' providing clear guidance on when to use this tool. It differentiates from siblings by focusing on queue status rather than history, stats, or other workflow operations, making it easy to choose this over alternatives like get_history or get_system_stats.
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/IO-AtelierTech/comfyui-mcp/badges/card.svg)](https://glama.ai/mcp/servers/IO-AtelierTech/comfyui-mcp)

Score Badge

Copy to your README.md:

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

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