comfy-draftsman

by EnragedAntelope

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool has a distinct purpose targeting a specific aspect of workflow management, from creation and editing to diagnosis and execution. No two tools serve overlapping functions; descriptions clearly differentiate them.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case, with verbs like create, diagnose, edit, export, get, import, inspect, lint, list, manage, organize, port, record, resolve, run, save, search, upload, validate, view. This makes the API predictable and easy to navigate.
Tool Count2/5
With 27 tools, the server exceeds the recommended range. While the tools are individually useful, the large number may overwhelm agents, and some tools (e.g., multiple workflow operations) could be consolidated.
Completeness4/5
The tool set covers the full lifecycle of workflow management, including creation, editing, validation, running, saving, and output retrieval. Minor gaps exist, such as the lack of a dedicated workflow deletion tool.
Average 4.2/5 across 27 of 27 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 63 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
The description indicates the tool persists data (write operation), consistent with readOnlyHint=false, but does not disclose key behavioral traits such as whether settings are merged or overwritten, what happens if the family already exists, or any side effects on existing data. Annotations provide only readOnlyHint, so description should fill gaps but does not fully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes inline examples that add verbosity. The structure is front-loaded with the main purpose, but the examples could be more succinctly presented. It remains readable and functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic usage and provides a special case for new families, but misses important behavioral details like merge/overwrite behavior. Since an output schema exists, return values are not required. The description is adequate but incomplete for a production tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining the 'updates' parameter with detailed examples of the guidance shape, clarifying 'source' as 'URL/model page', and explaining the 'family' parameter's behavior for new families (including detect block). This adds significant meaning beyond the schema titles.
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: 'Persist researched settings so FUTURE sessions start smarter.' It specifies verb ('persist') and resource ('settings'), and distinguishes from siblings by its unique function of recording guidance parameters for future use. Examples clarify the type of settings.
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 implicit usage context (e.g., 'Any family name works; for a NEW family also include a detect block'), but does not explicitly state when to use this tool versus alternatives or when not to use it. No sibling comparison or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only (readOnlyHint=true) and idempotent. The description adds the distinction between 'ui' and 'api' formats but does not elaborate on other behavioral traits like output format or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 18 words, front-loading the core purpose. No extraneous words; every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema exists), the description is adequate but could explicitly state that the output is a JSON string. It covers the key distinction between formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the burden is on the description. The description partially explains the 'format' parameter by defining the two enum values, but it does not mention the required 'workflow_id' parameter at all.
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?
Description clearly indicates the tool exports a workflow as JSON in two formats ('ui' and 'api') with brief explanations. It distinguishes from siblings like import_workflow, though the verb is implicit from the 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?
No explicit guidance on when to use this tool versus alternatives like save_workflow or port_workflow. The format descriptions hint at use cases but do not provide clear when-to-use or when-not-to-use advice.
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?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, indicating safe and stable behavior. The description adds useful context about templates being bundled and up-to-date, but does not provide further behavioral details beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loaded with the core purpose. Every word adds value without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having only one optional parameter and an output schema, the description fails to document the search parameter, leaving a significant gap. The agent cannot infer that filtering is possible without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description should explain the 'search' parameter, but it does not mention it at all. The agent has no guidance on how to use the optional search parameter to filter templates.
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 that the tool lists ComfyUI's bundled workflow templates, which are the best starting points for current models and ship with every release. It distinguishes from sibling tools by focusing on bundled templates, unlike list_workflows which likely lists user workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests using this tool to find templates to seed via create_workflow(template=...). It provides context about being the best starting points, but does not explicitly state when not to use it or compare with alternatives like list_workflows.
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?
The description discloses important behavioral traits beyond annotations: ops apply in order, a failing op stops the batch and reports successes, leaving the graph unchanged by the failing op. It also references get_node_info for output and widget names and notes support for annotation nodes. This adds value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence and a bulleted list of operations. It is efficient but could be slightly more concise by grouping common fields. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and the presence of an output schema (not shown), the description covers input parameters thoroughly, includes failure behavior, and references related tools. It is complete for the tool's purpose, though it could mention whether edits are saved automatically.
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% coverage for descriptions, but the description compensates by detailing each op structure with fields like 'op', 'class_type', 'node_id', etc. This adds significant meaning. However, the 'workflow_id' parameter is not described at all, leaving it implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Apply batched edits' and lists specific operations (add_node, remove_node, etc.), making it clear that the tool edits a workflow. However, it does not explicitly state the resource is a workflow, and it doesn't differentiate from sibling tools like organize_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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where batched edits are preferred or any prerequisites. The agent must infer usage from the operation list.
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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to repeat safety info. It adds no extra behavioral details (e.g., result limits, pagination), which is acceptable for a simple search 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?
A single sentence that conveys the tool's purpose and examples efficiently. No unnecessary words or structures.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter, comprehensive annotations, and an output schema (implied), the description is sufficiently complete. It covers the key use case and provides helpful examples.
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 sole parameter 'query' has no schema description, but the description provides concrete examples ('face detailer', 'wildcards') that clarify usage and format, adding value beyond the parameter name.
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 searches for node packs in the Comfy Registry by capability, with concrete examples. It distinguishes from siblings like 'search_nodes' by targeting node packs instead of nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'search_nodes' or other registry tools. The description only states what it does, not when or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, so description only adds that it returns a list of issues and 'Empty list = clean.' This is helpful but minimal beyond the 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?
Description is extremely concise: a single sentence with a specific list of lint checks and a note about empty results. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the main lint checks verbally and notes the return meaning. An output schema exists (not shown), so return values are partly covered. However, it does not mention if there are other checks beyond the listed ones or how verbose the output is. Still adequate for a lint tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one required parameter (workflow_id) with no description (coverage 0%). The description does not mention or explain this parameter, leaving the agent to guess what workflow_id refers to or how to obtain it. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool performs a 'lint' for readability and wiring issues, listing specific problems it checks (unlabeled prompts, missing groups/notes, orphan nodes, etc.). This distinguishes it from siblings like validate_workflow or diagnose_workflow, which likely handle different concerns.
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?
Description implies the tool is for static analysis of workflow readability and wiring, but provides no explicit when-to-use or when-not-to-use guidance compared to siblings like validate_workflow or run_workflow. Agent must infer from context.
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?
Annotations already indicate mutation and non-destructive behavior. The description adds the return value ('workflow_id + node summary') but does not elaborate on side effects, permissions, or other behavioral nuances. Value added is minimal beyond 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?
A single sentence that front-loads the action, then succinctly covers options and output. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and an output schema exists, the description covers the main intent and references list_templates for further context. It does not mention uniqueness constraints or error conditions, but these are secondary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the template parameter (blank vs seeded) but does not describe the title parameter beyond its name. Partial coverage leaves some meaning for agents to infer.
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 'start' and resource 'workflow', explains the two modes (blank or from template), and distinguishes from siblings like import_workflow. It also mentions the return value, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description recommends using a template and points to list_templates for available options, guiding usage. However, it does not explicitly exclude cases where import or edit would be preferable, leaving some guidance implicit.
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?
Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds specific behavioral details about what the status includes (queue position, live progress, outputs, errors).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose and includes all necessary details without waste.
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, the description covers the essential information about what the tool returns and its relation to run_workflow. Could mention non-blocking nature, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% – the description does not mention the sole parameter prompt_id. While the parameter is self-explanatory from context, the description fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the status of a workflow run, specifically those queued with run_workflow(wait=False). It lists the returned information (queue position, live progress, outputs, errors), distinguishing it from siblings like 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly connects to run_workflow(wait=False), indicating when to use. No exclusions or alternatives mentioned, but the context is clear given the tool's purpose.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description discloses that it mutates the session workflow in place, is idempotent, and summarizes changes in the 'applied' block. It adds context beyond annotations without contradiction.
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 two paragraphs with front-loaded key information starting with 'THE finishing step.' Each sentence provides value, though a minor trim could be possible. It balances detail and brevity well.
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 presence of an output schema, the description adequately covers the tool's purpose, actions, and result summary. It guides the agent to inspect_workflow for full details. Lacks edge cases or error conditions, but overall sufficient for correct 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?
With schema description coverage at 0%, the description does not explain the 'workflow_id' parameter. However, the single required parameter is self-explanatory from the tool name and context. The description adds no parameter-specific details, missing an opportunity to clarify format or constraints.
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 performs auto-layout into pipeline stage bands, colored groups, etc., and positions it as 'THE finishing step.' This is a specific verb-resource combination that distinguishes it from siblings like save_workflow or inspect_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to run after wiring is done and before save_workflow, and notes it is idempotent. This provides clear usage context, though it does not explicitly compare with alternatives or list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly and idempotent, and the description aligns by discussing retrieval of guidance. It adds behavioral context by mentioning inclusion of learned overlays and research directives, which are not captured by 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?
Three sentences pack essential information without fluff. The first sentence front-loads the core purpose, followed by variant usage and research context, making it efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return content, input usage, and connects to record_learning. The existing output schema compensates for missing return detail. A minor gap is the lack of explanation for default behavior when family/model_filename are empty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate. It explains model_filename's role in variant overrides but does not elaborate on family values. This partial explanation provides some added meaning but lacks full clarity.
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 returns tuned settings for a model family, including sampling, resolutions, technique blocks, and prompt style notes. It distinguishes from siblings like list_models by specifying it provides configuration guidance rather than mere listing.
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 usage context like passing model_filename for variant overrides and advises verifying brand-new models online and using record_learning. While it doesn't explicitly exclude alternatives, it effectively guides when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior (readOnlyHint=true, idempotentHint=true). The description adds value by detailing the output structure (nodes, links, groups, subgraph details), providing transparency beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Compact view of a session workflow') and then lists contents efficiently. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description adequately explains what the tool returns. It covers nodes, links, groups, and subgraph details, which is sufficient for an inspection tool. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one parameter (workflow_id) with 0% schema description coverage. The tool description does not mention or explain this parameter, leaving the agent to infer its meaning from context. This is insufficient; the description should compensate by clarifying the parameter's purpose and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'compact view of a session workflow' and lists specific components: nodes (with id/class/title/widgets), links, groups, and subgraph details. This distinguishes it from sibling tools like list_workflows (listing workflows) and get_node_info (single node info).
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 implies this tool is for inspecting workflow structure compactly, contrasting with other tools for listing or detailed node info. It does not explicitly state when not to use or list alternatives, but the context from sibling names provides sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with the description which details modifications (swaps, retunes, etc.) without claiming read-only or destructive behavior. The description adds behavioral context beyond annotations by listing specific changes and the return format with flags, though it does not mention any additional risks or edges.
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 compact and front-loaded with the essential purpose. It efficiently conveys scope, exclusions, and results in a few sentences. Minor density could be improved, but overall it is well-structured with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (model porting between families) and the presence of an output schema and annotations, the description covers the core functionality, usage boundaries, and outputs. It lacks explicit mention of prerequisites or detailed parameter ranges, but the context provided is largely sufficient for a qualified agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. While the overall description implies the role of target_family via the example, it does not provide explicit details about the parameters' meaning, allowed values, or format. The parameter names are self-explanatory to some extent, but the description misses an opportunity to add semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'CROSS-FAMILY MODEL PORT ONLY (e.g. "sdxl" -> "flux")' and details the operations performed (swaps loader topology, retunes CFG/steps/sampler/scheduler, etc.), making the tool's specific verb+resource clear and distinguishing it from siblings like diagnose_workflow and resolve_missing_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?
The description explicitly states when NOT to use the tool ('NOT for fixing missing/uninstalled nodes - that's diagnose_workflow + resolve_missing_nodes'), providing clear exclusions and alternative tools. It also indicates the tool returns changes and flags for judgment, guiding the agent on what to expect.
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?
Adds behavioral context beyond annotations: explains detail flag inlines schema. No contradictions with readOnlyHint, idempotentHint, openWorldHint.
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?
Three sentences, no wasted words. Purpose front-loaded. Each sentence adds distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, key parameters, and usage tips. Lacks explanation of limit and doesn't mention pagination or ordering, but output schema exists to cover return values.
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?
Compensates for 0% schema coverage by explaining query, category, and detail. However, limit parameter is only hinted at ('small limit') without explaining its effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (search) and resource (node classes). Distinguishes from siblings like get_node_info and search_node_packs by mentioning detail flag as alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit tips: use category to narrow, set detail=True to avoid follow-up. Lacks explicit when-not-to-use or alternatives for other cases.
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?
Annotations indicate readOnlyHint=false and openWorldHint=true. The description adds behavioral details: upload location (input folder), parameter exclusivity, and mask_for behavior. This supplements annotations without contradiction.
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: three sentences, front-loaded with purpose, and no waste. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and an output schema, the description covers core functionality and key use cases. Missing details for some parameters (name, overwrite, subfolder), but overall adequate for a tool with clear annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It clarifies the use of image_path, image_base64, and mask_for, but does not explain name, overwrite, subfolder. Partial coverage; adequate but incomplete.
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 uploads a source image into ComfyUI's input folder for use with LoadImage, specifying use cases like img2img/inpaint/ControlNet. It distinguishes from siblings by focusing on image upload rather than workflow management or output viewing.
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 usage (uploading images for LoadImage, exactly one of image_path or image_base64, mask_for for masks). It does not explicitly state when not to use or mention alternatives among siblings, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: that images are downscaled by default and that refs come from specific tools. No contradiction with annotations; they are consistent.
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, no fluff. Front-loaded with the primary action, followed by key usage details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and annotations providing safety, the description covers the essential context: source of inputs, scaling behavior. It could mention the output type but is adequate for a simple fetch 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?
With 0% schema description coverage, the description partially compensates by explaining the max_dim parameter. However, it does not detail type, filename, or subfolder in words, though these are self-explanatory from the schema. The added value is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch a rendered image') and the resource ('rendered image' from run_workflow/get_run_status outputs), and distinguishes it from sibling tools that create or run workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (after obtaining refs from run_workflow/get_run_status) and explains the scaling behavior (max_dim parameter). It does not explicitly state when not to use it, but the guidance is sufficient.
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?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds value by explaining that unknown folder values return the full list and that search is case-insensitive substring matching. This goes beyond annotations without contradicting them.
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, no fluff, front-loaded with purpose. Every sentence serves a clear purpose. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, annotations, and presence of output schema, the description provides all necessary context: parameter behavior and filtering logic. Complete for the agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully covers both parameters: folder with example values and behavior for unknown, search with case-insensitive substring behavior. This adds significant meaning beyond the bare 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 it lists model files installed on the instance, with the `folder` parameter selecting the model type (e.g., checkpoints, loras) and `search` for case-insensitive filename filtering. This distinguishes it from sibling tools which deal with workflows, nodes, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing to see available models, but does not explicitly state when not to use or name alternatives. Given the context, it is the only tool for listing models, but more explicit guidance would be helpful.
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?
Annotations already indicate read-only, idempotent, and open-world. The description adds specific data fields it returns, complementing the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no wasted words. The first sentence defines purpose, the second gives usage guidance. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is complete enough. It could mention that the output schema documents return values, but it's not necessary.
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?
No parameters exist, so schema coverage is 100%. The description doesn't need to add parameter details. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (ComfyUI instance) and the specific information returned (version, OS, VRAM, queue length). It distinguishes itself from sibling tools by being the only one dealing with instance info.
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 says 'Call first', providing clear guidance on when to use this tool. It doesn't exclude alternatives, but for a simple info retrieval tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds rich behavioral context beyond annotations: dual save location, validation error handling, naming strategy on conflict, and overwrite behavior. No contradiction with readOnlyHint=false or destructiveHint=false.
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?
Three sentences with clear front-loading: action first, then prerequisite, then key behaviors. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description adequately covers main behaviors. Could mention return value implications but is sufficient overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explicitly explain all parameters. It covers allow_invalid and overwrite behaviors but does not mention workflow_id or name, though their roles are inferable from 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?
Clearly states it saves the workflow in UI format to ComfyUI's workflow browser and session directory. Distinguishes from siblings like create_workflow and export_workflow_json by specifying the format and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to run organize_workflow first and explains refusal to save with validation errors unless allow_invalid=True. Names renaming behavior as an alternative to overwriting. Lacks direct comparison to other save-like siblings but provides sufficient contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, ensuring safe operation. The description adds behavior like live validation and closest-match suggestions, which go beyond annotations. No contradictions.
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, no wasted words, key information front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple validation checks), annotations (safe ops), output schema (exists), and single parameter, the description is fairly complete. It lists checks and hints at suggestions, but might lack detail on exact response format, which output schema likely covers.
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 only one parameter (workflow_id) and 0% schema description coverage, the description implicitly defines it as the target workflow for validation. The name is self-explanatory, and the description's focus on 'against the LIVE instance' provides sufficient context. Baseline for single param with no schema description is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a workflow against the live instance, listing specific checks (node classes, widget values, combo/model-file values, required inputs). It distinguishes from siblings like run_workflow (execution) and lint_workflow (likely static), 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 implies usage before run_workflow with 'Fix errors before run_workflow'. It provides context for when to use but does not explicitly mention alternatives or when not to use, though the context is clear enough for an AI agent.
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?
Annotations declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that it 'proposes fixes' but does not apply them directly, consistent with readOnly. It also mentions external resolution via Comfy Registry, aligning with openWorldHint. No contradictions, and description adds valuable context beyond 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 two sentences, front-loading the core purpose, and every part is informative. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one simple parameter and an output schema (not shown but assumed), the description provides enough context about the tool's behavior, relationship to siblings, and post-diagnosis steps. It is complete for a diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'workflow_id', which is self-explanatory from its name. Schema description coverage is 0%, so the description should add meaning. It implies the workflow is 'old/broken' but does not describe the parameter format or constraints. Adequate but minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a deep-check on old/broken workflows and proposes fixes, including everything from validate_workflow plus Comfy Registry resolution. It distinguishes from siblings like validate_workflow and port_workflow by specifying added capabilities and alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it for 'old/broken workflow' and provides alternatives: 'Apply fixes via edit_workflow, or port_workflow for model-family moves.' This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: data source (userdata), case-insensitive substring search. Annotations already indicate read-only and idempotent, which aligns with non-destructive listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading purpose and usage. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and an output schema, the description provides sufficient context: data source, filtering, and downstream 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?
With 0% schema description coverage, the description compensates by explaining the search parameter's behavior (case-insensitive substring filter) and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists saved workflows from userdata, explains how to use the returned names with import_workflow, and describes the search parameter. It distinguishes from sibling tools like import_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells when to use (to list saved workflows) and how to use the results (with import_workflow). It does not explicitly state when not to use, but the context is clear for a listing function.
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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that it returns pack ids, repos, and install hints, and warns about third-party code, providing valuable behavioral context beyond 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?
Three concise sentences, no unnecessary words. Front-loaded with purpose, then differentiator, then warning. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity, single parameter, and presence of output schema and annotations, the description covers the essential aspects: what it does, when to use it, return content, and a safety advisory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate. It mentions 'these node class names' but does not define what a class type is or provide examples, leaving room for ambiguity. However, the parameter is self-explanatory to some extent.
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 finds installable node packs for given node class names from the Comfy Registry, and distinguishes it from port_workflow, which is for model-family moves.
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 this is the tool for missing/uninstalled nodes and contrasts with port_workflow. Also provides a caution about third-party code, guiding user decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds valuable behavioral details: waiting behavior, preview thumbnail in response, save_dir relocation, and allow_invalid submission. It does not contradict annotations and provides context beyond structured fields.
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 fairly concise for the amount of detail, with front-loaded main action. Each sentence adds value, but it could be slightly shorter. Structure is logical: main behavior, then wait=False, allow_invalid, save_dir.
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 6 parameters and no output schema, the description covers return values (status, errors, refs, preview, saved_paths) and key behaviors. It misses explicit mention of return_preview control and timeout_seconds, but overall is complete enough 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?
Schema coverage is 0%, so description carries the burden. It explains wait, allow_invalid, save_dir, and implicitly return_preview (via preview thumbnail). It does not mention workflow_id (obvious) or timeout_seconds. Overall, it covers 4 of 6 parameters well, adding meaning beyond the schema titles.
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 queues a workflow and waits for completion, returning status, errors, output refs, and a preview thumbnail. It distinguishes itself from siblings like create_workflow, get_run_status, view_output, and save_output by emphasizing 'Prove a workflow works before saving/delivering' and noting that save_dir eliminates the need for a separate save_output step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: use to prove a workflow works; if wait=False, poll get_run_status; allow_invalid for local validator errors. It implies alternatives like view_output for full outputs and save_output if save_dir not used. However, it could explicitly state when not to use this tool versus diagnose_workflow or lint_workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond annotations: it explains that ComfyUI's save nodes cannot write to absolute paths, necessitating this relocation step. It also states the return structure ({saved_paths, dest_dir}). Annotations (readOnlyHint=false, openWorldHint=true) are consistent with this write-and-copy operation; no contradictions.
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 front-loaded with the core purpose. Each sentence adds value, but it could be slightly more concise, particularly the second paragraph which lists options in a slightly verbose manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no schema descriptions, but an output schema), the description covers the main workflow and return value. It lacks details on overwrite and subfolder/type usage, but the output schema and the mention of 'as reported in a run's outputs' provide enough context for an AI 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 description adds meaning beyond the schema for key parameters (prompt_id, filename, dest_dir, dest_filename), which is critical given 0% schema description coverage. However, parameters like type, subfolder, and overwrite are only mentioned in passing or not explained, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: copying finished renders from ComfyUI's output tree to a reachable folder. It explains the underlying reason (ComfyUI's save nodes are restricted) and distinguishes this tool from siblings like view_output or upload_image by focusing on file relocation.
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 usage guidance: use either prompt_id or explicit filename+subfolder/type, and explains defaults for dest_dir and dest_filename. It does not explicitly mention when not to use the tool or alternatives, but the guidance is sufficient for correct invocation.
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?
The description adds behavioral context beyond annotations: it explains the two input formats (UI vs. API) and the preferred method for large files. However, it does not explicitly state whether importing overwrites an existing workflow in the session or appends it. This minor omission prevents a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no superfluous words. It front-loads the main action ('Import an existing workflow into the session') and then efficiently details the methods and use cases. Every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters (none required) and an output schema, the description covers the main usage scenarios and parameter options. The minor gap is the unexplained 'title' parameter, which could affect completeness in edge cases. Overall, it provides sufficient context for most agents.
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?
Given 0% schema description coverage, the description compensates by detailing the semantics of 'workflow_json' (accepts both UI and API formats) and 'name' (loads from workflow browser, preferred for large files). However, the 'title' parameter is left unexplained, which is a gap for one of three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: importing an existing workflow into the session. It specifies two distinct methods (JSON via workflow_json or loading by name), which distinguishes it from sibling tools like create_workflow or list_workflows. The verb 'import' is specific and resource-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it explains the trade-offs between the two methods (JSON pasting vs. loading by name) and recommends the name-based approach for large files. It also mentions use cases (beautifying, diagnosing, porting) and references list_workflows as a complementary sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent. Description adds context on batch behavior, default combo cap, and filtering, which are beyond annotation fields.
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?
Three short paragraphs, each focused on a key aspect: purpose, batching, combo handling. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input parameters, batch optimization, and edge cases (long lists). Output schema exists, so return format details are not needed in description. Complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, description explains each parameter (class_type for single, class_types for batch, max_choices for cap, choices_filter for substring filter), adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full input/output schema for node classes', specifying the verb and resource. It distinguishes from sibling tools like search_nodes by focusing on schema retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on batching with class_types and handling large combo lists with choices_filter and max_choices. Tells when to use batch vs single call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), description details that clear/delete/interrupt discard queued work, and 'free' optionally unloads models. No contradiction; adds essential behavior 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?
Two succinct sentences: first states purpose and lists actions, second warns about side effects. Every sentence is necessary and well-structured, front-loading key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 5 actions, parameter usage, and destructive consequences. Output schema exists so return format is not needed. Complete for a tool with multiple destructive operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description fully explains each action and the meaning of 'unload_models'. It clarifies that 'prompt_ids' applies to 'delete'. Adds all meaning absent from 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 it manages the run queue with specific actions (status, interrupt, clear, delete, free). It distinguishes from sibling tools by focusing exclusively on queue operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises caution: 'clear/delete/interrupt discard other queued work - make sure that's what the user wants.' Guides appropriate use by flagging destructive actions.
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:

[![comfy-draftsman MCP server](https://glama.ai/mcp/servers/EnragedAntelope/comfy-draftsman/badges/card.svg)](https://glama.ai/mcp/servers/EnragedAntelope/comfy-draftsman)

Score Badge

Copy to your README.md:

[![comfy-draftsman MCP server](https://glama.ai/mcp/servers/EnragedAntelope/comfy-draftsman/badges/score.svg)](https://glama.ai/mcp/servers/EnragedAntelope/comfy-draftsman)

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/EnragedAntelope/comfy-draftsman'

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