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.15.1
Disambiguation4/5
Most tools have clearly separated roles: instance introspection, node/module discovery, workflow editing, workflow checking, execution, output handling, and queue management. A few pairs like get_instance_info/check_setup and lint_workflow/validate_workflow/diagnose_workflow are close enough to require careful reading, but they are not interchangeable.
Naming Consistency5/5
Every tool uses clear, predictable snake_case verb_noun naming: get_, list_, create_, import_, edit_, run_, save_, search_, and manage_ are applied consistently. The many *workflow tools all share the same suffix pattern, and there are no mixed conventions or vague verbs.
Tool Count4/5
At 29 tools, this is a heavy toolset, but the count maps fairly well to the broad ComfyUI lifecycle: setup, discovery, workflow creation/editing, validation/repair, execution, output retrieval, queue control, and persisted knowledge. It is slightly over-scoped, with a few validation/status/output tools that could theoretically be merged, but the count is not bloated given the domain.
Completeness4/5
The surface is nearly complete for a ComfyUI drafting assistant: one can discover nodes/models/templates, create and import workflows, edit and organize them, validate or diagnose them, run them, fetch outputs, upload images, manage the queue, and save or export the result. The main missing lifecycle niceties are explicit workflow deletion and uninstall/manage node packs, which are minor gaps rather than dead ends.
Average 4.3/5 across 29 of 29 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 70 commits in the last 12 weeks
- Last stable release on August 23, 2026
- 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, and idempotent behavior, so the safety profile is clear. The description adds meaningful behavioral context beyond the annotations by disclosing downscaling to max_dim and the full-resolution behavior when max_dim is None. It is honest about what it fetches and why the scaling behavior exists.
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 compact and front-loaded: it says what the tool is in the first clause and the why behind the behavior in the same breath. Every sentence earns its place, with no repeated information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, the description is a bit thin: It leaves filename semantics and the meaning of type/subfolder implicit, and it does not mention how the fetched image is returned to the agent. The source-of-truth pointer to run_workflow/get_run_status outputs helps, but more documentation would improve usability.
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 carries the responsibility for explaining parameters. It only explains max_dim and its resolution behavior. filename, type, and subfolder are left undocumented, and the description does not state how these map to the output refs received from run_workflow/get_run_status. This is a meaningful gap for an agent trying to invoke the tool correctly.
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 identifies the action ('Fetch a rendered image') and why it is used ('so you and the user can SEE it'). It also anchors the image source to run_workflow/get_run_status outputs, which helps differentiate this viewer from the workflow-management siblings. It does not explicitly name or distinguish a sibling tool, so it stops just short of 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 the intended use: fetch an image after running a workflow and looking at run status output. It does not explicitly state when not to use this tool or mention alternatives such as save_output, upload_image, or get_run_status. Some usage context is present, but it is largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only and destructive hints without contradiction. The description adds that the tool returns 'workflow_id + node summary' and that a template can seed the workflow, which is helpful. Still, it doesn't clarify persistence, side effects, or what happens if the template is invalid.
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 tight sentences, front-loaded with the core action, and no redundant wording. Every phrase adds signal: blank vs template, recommendation, template source, and output.
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 creation tool with a single required parameter and one template optional parameter, the description is mostly complete. The return value is mentioned, and the template source is provided. Minor missing detail is what exactly a node summary contains, but the presence of an output schema lowers the burden on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description partially compensates by explaining that 'template' seeds from a bundled template and telling the user to consult list_templates. However, it does not explain the required 'title' parameter or specify the expected template identifier format.
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 identifies the operation: start/create a workflow, with the key options 'blank' or 'seeded from a bundled template'. It also signals the output. However, it does not explicitly distinguish itself from sibling tools like run_workflow, import_workflow, or save_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?
It gives useful context about when to prefer a template ('recommended for current model families') and points to list_templates. However, it does not clearly state when to use this tool over alternatives such as import_workflow or run_workflow, or provide any 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?
Annotations already declare the tool read-only and idempotent, and the description adds meaningful behavioral detail by explaining the purpose and effect of each output format. The described behavior is consistent with the read-only annotation since it presents an export/rendering action rather than a mutating one.
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, tightly written sentence places the core concept first and packs precise format guidance into a minimal structure. There is no filler 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?
Given that an output schema is present and the annotations cover read-only and idempotency, the description provides sufficient context for selecting between formats. The main gap is that it doesn't mention how the workflow_id is obtained or when to choose this tool over alternative workflow-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate for parameter meaning. It thoroughly explains the 'format' parameter's enum values, but it does not explicitly describe 'workflow_id', even though the name and type make its role largely self-evident.
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 returns a workflow as JSON and distinguishes between the 'ui' and 'api' export formats. It relies on the tool name and the two format options to convey the export action, and it does not explicitly differentiate this tool from sibling tools, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance on which format to use: 'ui' for a shareable editor-compatible JSON and 'api' for POST /prompt automation. It provides clear context for the tool's main decision but does not explain when to reach for this tool over siblings like save_workflow or inspect_workflow.
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?
The description communicates that this is an import action that modifies the session and that it can read from either pasted JSON or a named workflow. It does not disclose whether importing replaces/merges the current session workflow, what happens if both parameters are supplied, or error behavior on invalid JSON. Annotations don't contradict it, but they don't carry much behavioral weight either.
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: the core action appears first, then the two parameter modes, then the usage purpose. The final phrase 'porting outside work' is slightly awkward, but each sentence contributes useful information without bloating the description.
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 only two optional parameters and an output schema, the description is nearly sufficient. It explains the two mutually exclusive input options and names the companion list_workflows lookup. The main remaining gaps are precedence if both parameters are set and how an invalid or missing workflow is handled, but these are minor for choosing and invoking the tool.
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?
Schema description coverage is 0%, so the description must compensate, and it does thoroughly. It explains exactly what `workflow_json` accepts (UI format with nodes/links or API format) and what `name` refers to (a workflow from ComfyUI's browser, obtainable via list_workflows). This is precisely the information an agent needs beyond the bare 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 identifies the verb and resource: import an existing workflow into the session, and it distinguishes the two supported input modes. It could more explicitly differentiate itself from create_workflow or port_workflow, but 'existing' workflow and 'import... into the session' make the core purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool: for beautifying, diagnosing, or porting outside work, and it tells the agent that the `name` path is preferred for large files. It points to list_workflows for resolving workflow names. It does not explicitly state when not to use it or which sibling to prefer instead, but the guidance is reasonably concrete.
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 report readOnly, openWorld, and idempotent, and the description's 'search' wording is consistent. It adds the domain context of the Comfy Registry, but it does not disclose extra behavioral details such as rate limits, result size, pagination, or permissions.
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 explains the operation, resource, scope, and examples real.true. There is no filler, repetition, or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This compact one-parameter, read-only, idempotent search tool with an output schema needs only modest explanation. The description succeeds exception it could not mention whether the query accepts natural language, exact terms, or a specific search syntax.
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 only says 'query' is a string, so the description must compensate for the bare schema. It tells the agent that the query should be a capability and gives meaningful examples ('face detailer', 'wildcards', 'video interpolation'), making the parameter's intended semantics clear despite no extra schema help.
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 an operation ('search'), a resource ('Comfy Registry node packs'), and the search facet ('by capability') with concrete examples. This distinguishes it from sibling search_nodes because it targets node packs rather than nodes or other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The capability examples imply when the tool should be used, but the description never explains when to prefer it over search_nodes or another sibling. There is no explicit exclusion, alternative routing, or contextual condition beyond the phrase 'by capability.'
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?
It clearly communicates that validation happens against the live instance and includes detailed behaviors such as 'closest-match suggestions'. This adds practical nuance beyond the readOnlyHint/idempotentHint annotations. No contradictory behavior is implied.
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 main purpose. Every clause adds meaningful detail, though the closing instruction 'Fix errors before run_workflow' is a behavioral guideline rather than a descriptive detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the key validation dimensions and current environment scope, and the output schema handles structured return information. The only minor gap is the absence of explicit mention whether validation fully blocks execution or merely warns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter, workflow_id, but the description never explicitly explains this parameter beyond the inferred meaning of 'validate the workflow'. With schema description coverage at 0%, the description should compensate, and it does not add direct parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific action and target: 'Validate against the LIVE instance'. It enumerates concrete validation checks (node classes installed, widget values, combo/model-file values, required inputs connected), which clearly separates this from static analysis tools like lint_workflow or diagnose_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Fix errors before run_workflow' makes the intended context explicit: this is a pre-flight validation step before execution. It does not name alternatives or state when not to use this tool, so it stops short of the strongest form of usage 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 readOnly, idempotent, and openWorld behavior. The description adds useful behavioral context by specifying that the relocation block reports whether COMFYUI_MOUNT_DIR is set and writable, and what the consequence is when it is not. This goes beyond what annotations alone convey.
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 short and front-loads the concrete output fields before giving the call-order and relocation caveat. Every sentence earns its keep, though the final sentence could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no inputs and an output schema, the description only needs to clarify when to call the tool and what to do with a critical result. It does both, including concrete reasons for checking relocation readiness before starting render work.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the 0-parameter baseline of 4 is appropriate. There are no parameters for the description to document, and it correctly focuses on what the returned metadata means.
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 enumerates the exact data returned: ComfyUI version, OS, VRAM, queue length, and render-relocation readiness, and additionally says to call it first. This is clear even though it lacks a full verb phrase, and the 'Call first' instruction gives it a distinct role among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: call this tool first, and before spending a render, surface the relocation readiness issue to the user. It does not explicitly name or exclude alternatives, so it misses the highest level of routing context.
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 meaningful behavior beyond annotations: results may include learned overlay from past research, a research directive, variant-aware overrides, and a fit block that only appears when the GPU cannot hold the model. This helps the agent anticipate dynamic or conditional output content.
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 dense but well organized: core purpose first, then variant-aware usage, then learned/research behavior, then a conditional output note. Every sentence adds new useful information and none is redundant.
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 output schema and strong annotations, the description covers the main behavioral and usage nuances: what the guidance includes, when variant overrides apply, when to research external information, and when the fit block appears. The main gap is that parameter defaults and family semantics are not fully spelled out, but the description is still strong enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain model_filename as a variant override selector, and family is inferable as the model-family identifier. However, it does not specify valid or default values for either parameter, what happens when both are empty, or how family and model_filename interact more precisely.
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 identifies the exact deliverable—tuned settings for a model family—and enumerates its content: sampling settings, resolutions, technique blocks, and prompt style notes. It is clear enough to distinguish from sibling tools like get_node_info or list_models, but it never uses an explicit retrieval verb beyond the name 'get_model_guidance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: pass model_filename so variant-specific overrides apply, and for brand-new models verify online and call record_learning. It lacks explicit comparisons like 'use this instead of X' or 'not for Y', but it gives enough situational guidance for choosing and using 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?
The annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering safety and side effects. The description adds useful behavioral context: it returns an empty list when clean, it detects orphan nodes, unconnected inputs, empty list means clean, and it narrows the alignment check to families with a known alignment requirement. No contradiction with 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 tight, front-loaded, and information-dense. 'Readability/wiring lint:' establishes the purpose, a concise list defines scope, and 'Empty list = clean.' closes with an unambiguous contract. There is no redundant filler.
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 read-only lint with an output schema, the description covers the necessary behavioral and scoping details well. The only contextual gap is the undocumented workflow_id parameter semantics, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only says workflow_id is a required string, with 0% description coverage. The tool description does not explain what a workflow_id should look like, where to obtain it, or how it is used in the lint. The parameter name provides a minimal hint, but the description fails to compensate for the empty schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb and resource precisely: a readability/wiring lint. It then enumerates the specific classes of issues it detects, which strongly separates it from generic validation or diagnostic siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly scopes the tool to readability and wiring concerns by naming concrete lint categories, so an agent can infer when to use it. It does not explicitly or alternately, but the sibling names like validate_workflow and diagnose_workflow make the distinction fairly obvious.
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 discloses several non-obvious behaviors beyond the annotations: it refuses invalid saves unless allow_invalid=True, never overwrites by default, renames collisions to '<name> (dartsman)', reports this through result.renamed_from, and replaces only when overwrite=True. The annotation destructiveHint=false is compatible with the default non-destructive path; overwrite is an explicit opt-in rather than an annotation 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 dense but every clause adds information: purpose/format, prerequisite/mission, validation behavior, collision behavior, and overwrite semantics. There is no filler or repetition of schema/annotation fields, and the most important purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with an output schema, the description covers the key invocation constraints: prerequisite, validation gating, overwrite risk, and collision naming. The main gap is that workflow_id and name are not explained in the description, so the agent must rely on parameter names and schema type information.
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 descriptions cover 0% of the parameters, so the description must compensate. It does explain the behavior of allow_invalid and overwrite, and the naming behavior around name collisions, but it never explicitly explains workflow_id or that name is the new save name. These are inferable, but the description leaves part of the parameter-load to the agent.
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 identifies the action ('Save the workflow'), the resource ('UI format, with layout/groups/notes'), and the destination ('ComfyUI's workflow browser + session dir'). It does not explicitly name a sibling it is not, but the UI-format qualifier and the mention of session-dir saving distinguish it from export-only or output-saving tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete precondition ('Run organize_workflow first'), explicitly says this is the deliverable, and explains when validation errors block saving unless allow_invalid=True. It does not explicitly contrast itself with sibling tools such as export_workflow_json or save_output, so the routing guidance is clear but not comprehensive.
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 carry readOnlyHint, openWorldHint=false, and idempotentHint=true. The description adds meaningful behavioral detail by specifying the compact scope and the fact that subgraph definitions can contain full inner node/wiring detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence packs in purpose, content, and the subgraph caveat without redundant words. Front-loaded key phrase 'Compact view of a session workflow'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one simple parameter and an output schema present, the description provides enough for immediate use: it describes the structural view, node details, group views, and subgraph coverage. It does not provide parameter lookup guidance, but this is minor given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries full responsibility for parameter meaning. Although workflow_id's purpose is inferable from the tool name, the description adds no explicit detail about the parameter's format, origin, or relationship to resources like list_workflows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a compact inspection view of a session workflow, enumerating what is included (nodes, links, groups, and subgraph detail). This distinguishes it from siblings like get_node_info or search_nodes that cover only a narrow portion of workflow structure.
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 provides clear context: use this tool to get a compact structural overview of a workflow, with expanded detail for subgraph definitions. It implies when the tool is appropriate but does not explicitly name alternatives or conditions 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?
With annotations present (readOnlyHint=false, destructiveHint=false), the bar is lower, and the description adds real behavioral context: persistence affects future sessions, a 'detect' block enables auto-recognition next session, and the tool 'never invents a URL, so this is the only way one appears' — a genuine policy disclosure. It also instructs URL verification before recording. Nothing contradicts the annotations: readOnlyHint=false is consistent with a persist 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 somewhat long, but every segment earns space: the purpose is front-loaded, the updates shape needs its examples, and the NEW-family and sources-list paragraphs cover mandatory edge cases. It is densely structured with little fluff, though the many inline JSON examples make it verbose by necessity.
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?
All three required parameters are explained, edge cases (new family detection, sources-only URL introduction) are covered, and an output schema exists, so return values need no explanation. The remaining gaps are minor: it presupposes familiarity with 'the guidance shape', and it does not describe what happens on failure or how recorded settings interact with get_model_guidance. For a high-complexity tool the description is still complete enough for a first-call agent.
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?
Schema coverage is 0%, so the description carries the full burden and fully compensates: it assigns meaning to 'family' (any family name, with the NEW-family detect/loader variant), 'source' (URL/model page) and 'updates', with concrete shape examples such as {"sampling": {"cfg": {"default": 3.5}}}. It also explains the separate 'sources' list block and how the pattern matches checkpoint filenames. This is exemplary parameter documentation for a 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 opens with a precise verb+resource: 'Persist researched settings so FUTURE sessions start smarter.' This clearly expresses a write/update operation over a learning/guidance resource, which is readily distinguishable from the retrieval-oriented sibling get_model_guidance and from organize_workflow. The intent is unambiguous even without reading the schema.
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 is rich with intra-tool guidance: when updating provide the guidance shape, for a NEW family include a detect block, and include a sources list only to introduce URLs. However, it does not explicitly say when to use this tool vs. the alternatives (e.g., get_model_guidance for the read side of the same data), nor does it state any exclusions or conditions that would route an agent elsewhere.
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 cover readOnly, idempotent, and openWorld semantics. The description adds useful context about the data source (userdata) and search behavior, but does not go much deeper; no contradiction with 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, all relevant. The core resource is front-loaded, the related tool is referenced, and the parameter semantics are stated precisely without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list-type tool with one optional parameter and an output schema, the description fully covers data source, filtering behavior, and intended next step. Missing return details are not an issue because an output schema exists.
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 provides only a bare string with a default and zero description coverage, but the description explains exactly what the search does: case-insensitive substring filtering of names. That is sufficient for a single optional parameter.
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?
States a clear verb+resource: lists saved Workflow browser workflows from userdata. It also distinguishes itself from import_workflow by indicating these are already-saved items, not arbitrary JSON.
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 connects to import_workflow(name=...) as the follow-up action, giving the agent an immediate workflow chain. It does not spell out when to choose list_workflows over find_workflow or other siblings, so a tiny gap remains.
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 convey read-only and idempotent behavior. The description goes further by detailing what the tool reports: queue position, live step progress, and outputs/error details. The only omission is any discussion of poll cadence or rate limits, but the provided context is solid.
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 brief and starts with the most important purpose-context right away. It loses a point because the same phrase 'runs queued with run_workflow(wait=False)' is repeated twice in the text, slightly reducing efficiency.
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?
With one simple parameter, a clarifying notation about returns available through an output schema, and clear routing guidance, the description gives the agent enough to select and invoke this tool effectively. It also anticipates the main sibling-tool confusion via long-render vs. polling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for prompt_id. It implies that prompt_id relates to a run queued with run_workflow(wait=False), but does not explicitly say 'pass the prompt_id returned by run_workflow' or describe its format. This is adequate for a single obvious parameter but not fully explicit.
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 identifies the tool as a polling companion for run_workflow(wait=False), with the exact fields it returns: queue position, live step progress, and outputs/errors. It also distinguishes itself from run_workflow's long-render pattern, making its purpose unambiguous among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool: to poll a run queued with run_workflow(wait=False). It also tells the agent to see run_workflow's long-render pattern for long/paid renders, providing an explicit alternative condition.
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 are minimal but the description goes beyond them by explaining that the tool swaps, rewrites, repicks, and retunes a workflow, and that it returns changes plus flags for human judgment. This gives the agent a realistic picture of the mutation behavior, though it stops short of spelling out every side effect (e.g., whether original workflow files are modified in place).
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 dense but every sentence/segment pulls its weight: scope, concrete behavior, exclusion, alternatives, and output summary. There is no filler and the crucial 'CROSS-FAMILY ONLY' constraint is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no schema descriptions, and no enums, the description supplies most of what an agent needs: purpose, scope, help resources, and what the return value indicates. The main missing piece is a precise mapping/example of the two arguments, which the succinct schema alone does not provide, but the overall behavior is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description carries the burden for parameter meaning. It communicates that `target_family` is a model family (via the sdxl->flux example) and `workflow_id` is implicitly the workflow being ported, but it does not explicitly name either parameter or list valid families. It partially compensates but leaves the exact value-space and workflow_id semantics to the agent.
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 begins with a very specific scope, 'CROSS-FAMILY MODEL PORT ONLY', and gives a concrete example ('sdxl' -> 'flux'). It then enumerates exactly what the tool does: swaps loader topology, retunes CFG/steps/sampler/scheduler, swaps latent node class, and picks model files. This clearly distinguishes it from generic editing or diagnostic tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when NOT to use it ('NOT for fixing missing/uninstalled nodes') and names the exact alternative tools to use instead ('diagnose_workflow + resolve_missing_nodes'). It also points to supporting tools for family knowledge ('get_model_guidance / get_instance_info'), leaving minimal inference for the 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 already indicate this is not read-only and not destructive. The description adds valuable behavioral detail: ComfyUI save nodes reject absolute paths, the tool relocates output files, dest_dir defaults to COMFYUI_MOUNT_DIR, and the return contains saved_paths and dest_dir. The only mild gap is not detailing overwrite semantics, but that is covered enough by the parameter names and defaults.
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 compact and front-loaded. The first sentence states the purpose, the second gives the 'why', and the subsequent sentences explain usage and return value. Every sentence adds useful information, and nothing feels repetitive or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is nearly complete for a 7-parameter tool, covering the major options and the return shape, and an output schema exists. It could be slightly more explicit about how overwrite and type/subfolder combine with filename, but the essential knowledge an agent needs to run the command is present.
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 must carry the parameter-load. It explains prompt_id, filename, dest_dir, and dest_filename well, and refers to subfolder/type inferring their usage. It does not explicitly define every parameter (e.g., overwrite), but the core selection logic is clear and materially more helpful than 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 opens with a clear action and scope: 'Copy a finished render out of ComfyUI's output tree into a folder the caller can reach.' It identifies the source, the destination constraint, and the rationale, so an agent knows exactly what this tool does and how it differs from purely viewing or uploading content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong context on why relocation is needed and explains the two invocation modes: pass a prompt_id for all outputs or a filename for a single file. It does not explicitly list when to choose alternatives, but the use case is well scoped and the two modes are clearly contrasted.
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 meaningful behavioral context beyond the sparse annotations: the uploaded file lands in the input folder, exactly one of image_path or image_base64 must be supplied, and mask_for changes the behavior to upload as a MASK instead of an image. It does not cover the effect of the overwrite parameter, which could be a destructive operation, nor the filename derivation semantics; this is a minor gap given the destructiveHint annotation.
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 filler; the core purpose is front-loaded and the second sentence captures the two critical behavior twists (exclusivity and mask mode). Every sentence earns its place and does not repeat schema contents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's real complexity (6 params, 0% schema coverage, limited annotations), the description covers the highest-risk information: the destination, the input modes, and the mask variant. An output schema exists so the return value is already covered, but the description still omits overwrite and subfolder edge behavior, which an agent may need for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden and largely delivers: it explains image_path (local file) vs image_base64, their mutual exclusivity, and decomposes mask_for's shape with its subfields. It is silent on name, subfolder, and overwrite, whose semantics are inferable from their names and defaults, so the compensation is solid but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: uploads a source image into ComfyUI's input folder so LoadImage can use it, and names the use cases (img2img / inpaint / ControlNet). This clearly distinguishes it from the sibling tools, especially save_output which moves data out rather than into the ComfyUI input folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use this tool: before workflows that need LoadImage to reference an input image for img2img, inpaint, or ControlNet. It documents the exclusive either/or of image_path vs image_base64 and the mask_for alternative mode. It does not explicitly state when not to use it or name a sibling as an alternative, so no exclusion is given.
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 and idempotentHint, so the safety profile is covered. The description adds transparency by stating that the tool only proposes fixes and that actual modification should happen through edit_workflow or port_workflow, which is consistent with the annotations and extends the 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 dense but short: two sentences, with the primary purpose front-loaded and follow-up routing placed at the end. Every clause earns its place without wasting the agent's attention.
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 read-only diagnostic tool with one obvious parameter and an output schema, the description gives enough guidance for correct invocation and follow-up. It clarifies relationship with validate_workflow, edit_workflow, and port_workflow, so the agent can decide when and how to use it.
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 is only one parameter, workflow_id, and its name plus schema type already make the meaning obvious. Although schema description coverage is 0%, the low parameter complexity and the repeated workflow context in the description reduce the impact of having no additional parameter-level explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a concrete verb ('Deep-check') and identifies the exact resource ('workflow') and the expected outcome ('propose fixes'). It explicitly positions itself as a superset of validate_workflow and adds Comfy Registry resolution for missing custom-node classes, making it easy to distinguish from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear selection context: use this for old/broken workflows that need deeper diagnosis and repair proposals, and it routes follow-up actions to edit_workflow or port_workflow for model-family moves. It does not explicitly say 'when not to use this tool', but the superset relationship with validate_workflow, plus the explicit alternatives makes the usage boundary fairly clear.
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 readOnly, openWorld, and idempotent hints. The description adds meaningful behavioral context: it returns ranked compact summaries only, never full graphs, and it covers hand-built workflows by extracting profiles from saved JSON. No-match behavior is not mentioned, but that is a minor gap given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but every sentence earns its place: purpose, query example, output shape, coverage characteristics, and the alternative tool. It is front-loaded with the key value proposition and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema, the description does not need to explain return types in detail. It covers the motivation, input guidance, output summary, safety via annotations, and the appropriate follow-up tool enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is zero, so the description carries the burden. It explains the intent parameter well with an example ('flux portrait at 1024 with a face detailer') and implied fields like model/subject/resolution/extras. However, the limit parameter is not explicitly described, only vaguely implied by 'a few ranked matches.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('find') with a clear resource ('saved workflows') and a distinct purpose: reuse existing workflows instead of rebuilding. It differentiates itself from list_workflows and import_workflow by describing intent-based ranking search and by explicitly saying it returns summaries only, not full graphs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Prefer this over importing+inspecting each result of list_workflows.' It also explains how to formulate the intent query and points the user to import_workflow(name=...) when a full graph is needed.
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 goes well beyond the annotations by explicitly stating that the tool MUTATES the session workflow in place and is idempotent. It also explains what the result contains (the applied block) and how to see the full reorganized graph, which is valuable context that the annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but information-dense: two sentences carry purpose, sequencing, mutation semantics, idempotence, and output behavior. The key instruction is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main operational requirements: when to call it, what it mutates, idempotence, what the result contains, and how to inspect the complete output. Since an output schema exists, the description does not need to restate return values, and it gives the agent enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage for workflow_id is 0%, and the description does not explain workflow_id explicitly. However, the repeated mention of 'session workflow' and 'workflow' implies that this ID selects the target workflow to be organized. For a single, self-describing identifier parameter, this is adequate but not fully explicit compensation.
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 names a clear verb and resource: it auto-layouts the workflow into pipeline stage bands, colored groups, human titles, highlights, and guidance notes. It also distinguishes itself from sibling tools by being explicitly 'the finishing step' before save_workflow, rather than an inspection, validation, or save operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear lifecycle guidance: run after wiring and before save_workflow. It also tells the agent that inspect_workflow or export_workflow_json can be used afterward to view the full result. It does not explicitly name alternatives for when not to use it, so it falls just short of a perfect dimension.
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, so the description is free to add context. It does so by specifying that the tool returns pack ids, repos, and install hints, and by flagging the third-party code risk associated with installing custom nodes. This adds meaningful behavioral context without contradicting 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?
The description is tight and purposeful: a clear first sentence names the tool's function, the second distinguishes it from a sibling, and the third adds output and risk context. Every sentence earns its place without padding.
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 single-parameter tool with an output schema and three annotations, the description covers purpose, selection criteria, return values, and the important user-consent caveat. There is no major contextual gap for an agent to successfully select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It usefully clarifies the parameter as node class names, but it does not fully explain the expected format or source of those class names beyond their obvious semantic connection to missing nodes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: find which installable node packs provide the queried node class names, scoped to the official Comfy Registry. It also explicitly states this is the tool for missing/uninstalled nodes and names a sibling tool it is not, making differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit boundary: use this for missing/uninstalled nodes, while port_workflow is for model-family moves and not for missing nodes. It also gives operational guidance by warning that installing custom nodes runs third-party code, so the user's choice must be surfaced.
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 cover read-only/idempotent/open world aspects. The description adds useful behavioral context: what fields are searched, how category narrows results, and that detail=True folds full I/O schema into each hit, letting the agent avoid a second call. No contradictions with the read-only/idempotent hints.
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 compact sentences front-load the core purpose and then give targeted usage and efficiency tips. Every clause adds value, no redundancy or filler. The structure is easy to parse for an agent: search, narrow, get details as needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for this read-only search tool given the output schema and annotations. It tells the agent what it searches, how to narrow with category, when to request detail, and how to avoid a follow-up get_node_info. Nothing essential for selecting or invoking this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It explains query semantics (search over name/display-name/description), category (narrow with examples), detail (in-line schema), and limit (small limit when using detail). It doesn't describe the bare 'limit' term, but that is semantically evident from the schema default.
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?
States a specific verb and resource: 'Search node classes installed on the instance' with explicit match fields (name/display-name/description). It distinguishes itself from sibling tools by noting that setting detail=True lets you 'skip the follow-up get_node_info', and the word 'classes' separates it from search_node_packs.
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 actionable guidance with concrete category examples ('loaders', 'conditioning', 'sampling', 'ImpactPack') and a rule for detail usage: set detail=True with a specific query and small limit to skip get_node_info. It clearly explains how to adjust behavior, though it doesn't enumerate when *not* to use this tool versus all possible siblings.
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 annotations already signal read-only, idempotent, and open-world behavior, so the description adds real value by explaining conditional behavior: unknown folder values produce the full list, search is case-insensitive substring matching, and metadata_for switches from listing to embedded training metadata. These are precisely the behaviors an agent would not infer from the schema or 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 compact and front-loaded with the primary purpose. Each sentence earns its place, and even the longer metadata_for sentence is dense with useful, non-redundant detail.
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 output schema exists, the description does not need to explain return shapes. It covers default-oriented behavior, edge cases like unknown folders, search matching, and the special metadata_for mode, making the tool safe and effective to invoke correctly.
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?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It fully compensates by explaining folder with examples and fallback behavior, clarifying search semantics, and defining metadata_for's special behavior.
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 identifies the resource as 'model files installed on the instance' and makes the tool's scope obvious relative to workflow/template siblings. However, it lacks an explicit verb such as 'lists' or 'returns' in the opening sentence, relying partly on the tool name to establish the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational guidance: folder selects the model category, search filters filenames, and metadata_for fetches metadata instead. It does not explicitly name alternatives or exclusions among the sibling tools, but the context strongly implies when this read-only model-listing tool is appropriate.
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 valuable behavior beyond those, including catalog size, bundled origin, and how search matches title/description/models. This context is consistent and meaningful.
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 sentences carry the full needed context: what the tool returns, how to use the result, and how/when to narrow. No filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter read-only tool with an output schema and safety annotations, so the description doesn't need to explain return values. It provides the extra operational context about catalog size and downstream use that makes the tool easy to invoke correctly.
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 description coverage, the description compensates completely by explaining that search is a narrowing filter against title, description, and models. Since there is only one optional parameter, this is sufficient for correct use.
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 identifies the resource (ComfyUI's bundled workflow templates) and the action (listing a catalog of them), adding scope by noting they ship with every release and are the best starting points. This distinguishes it from siblings like list_workflows because it's specifically bundled templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete usage guidance: narrow with search= and use the result to seed via create_workflow(template=...). It also warns about the catalog size, which implies you should not simply fetch everything. It doesn't spell out when-not-to-use alternatives, but the practical context is clear.
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 goes well beyond the annotations by explaining the exact destructive scope: clear drops ALL pending prompts, delete drops specific prompt_ids, and interrupt stops the running prompt. It also discloses side effects such as 'free' releasing cached VRAM/RAM and unload_models=True unloading models, plus the ownership guard for prompts queued by other sessions.
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 dense but extremely information efficient, with every phrase adding essential detail. It is front-loaded with the main purpose and action list, then covers safety constraints. No filler or redundant statements appear.
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 complex multi-action behavior, destructive annotations, and 4 parameters, the description is complete: it covers all actions, gating requirements, session ownership semantics, confirmation flow, and memory/model side effects. An output schema exists, so return-value description is not required.
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?
Schema description coverage is 0%, so the description must compensate. It does: the 'action' enum values are all described, 'prompt_ids' context is established via 'delete (drop given pending prompt_ids)', 'confirm' is explained via gating and user agreement, and 'unload_models' is explicitly tied to model unloading. Every parameter receives meaningful semantic explanation.
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: 'Inspect or manage the instance's run queue' and enumerates distinct actions. It is specific about the resource and verb, though it does not explicitly differentiate itself from sibling tools like get_run_status.
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 useful guidance about when actions are allowed, noting that clear/delete/interrupt are 'gated when they'd discard prompts this session didn't queue' and that 'confirm=True' is needed once the user agrees. It does not explicitly mention alternatives or when to choose a sibling tool instead, but the action-by-action breakdown gives clear context.
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 confirm read-only, idempotent behavior. The description adds meaningful behavioral details beyond annotations: combo lists are capped at 24 choices by default, choices_filter is substring-based and case-insensitive, and it is applied to every combo of the node. This is exactly the behavioral context an agent needs to correctly interpret limited results.
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 tightly organized and every sentence conveys operational value. It front-loads what the tool returns, then covers batching efficiency, single vs batch return shape, and list-cap behavior without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter read-only tool with an output schema, the description is complete: it covers all parameters in practice, explains both invocation modes and their return structures, and clarifies the only surprising behavior (cap and filtering of combo choices). Nothing critical is left to inference.
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 tool description carries the parameter semantics, and it does so well for class_type, class_types, and choices_filter. The only ambiguity is max_choices: the schema default is 0 while the text says 24 is the default cap, leaving it unclear whether max_choices=0 means 'use the default cap' or 'no limit'.
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 identifies the resource as node-class schemas and enumerates exactly what is returned: slot names, types, widget defaults/ranges, combo choices, and tooltips. It further distinguishes single vs batch return shapes, which makes the tool's behavior unambiguous and distinguishes it from sibling lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage direction: batch lookups with class_types when multiple schemas are needed, and use choices_filter/max_choices to control long combo lists. It does not explicitly name alternative tools or exclusionary conditions, so the when-to-use guidance is clear but not fully comparative.
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?
Even with annotations declaring readOnlyHint, openWorldHint, and idempotentHint, the description adds behavioral context beyond them: it never raises, a down instance is a failed check rather than an error, and it explains the gate ('ok gates on ComfyUI reachable') and soft checks ('relocation is a soft check surfaced via hint'). This is substantial 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: three sentences cover purpose, usage guidance, behavioral guarantee, and return shape. It front-loads the core diagnostic role and avoids fluff, making it easy for an agent to parse quickly.
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?
With no parameters and a rich output schema, the description still provides the non-obvious context: what the checks mean, how to interpret the response gates, and how it behaves on a down instance. Combined with the annotations and output schema, an agent has everything needed to correctly invoke and interpret this 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?
There are zero parameters, so no parameter semantics are needed. The description adds meaning by detailing what the diagnostic checks and how the results are structured, which effectively covers the absence of 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 is a 'one-shot setup diagnostic' and enumerates the exact three checks: ComfyUI reachability, render handoff via COMFYUI_MOUNT_DIR, and partner-node key presence. It explicitly contrasts itself with get_instance_info, making the agent able to discriminate the tool from siblings without inspecting the schema.
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 says both what the tool is for ('fresh install or a sandboxed client (Cowork/Desktop/Code)') and gives concrete when-to-use guidance: 'run it first when a render can't be delivered or the instance seems unreachable.' It also provides an exclusion by contrasting with get_instance_info, which raises on a down instance.
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?
Without rich annotations, the description carries the burden and exceeds it: it explains seed re-rolling and persistence versus the raw /prompt API, server-side validation authority, spending gates, timeout behavior that does not kill the ComfyUI job, and recovery via draftsman_submitted after the session dies. This is substantial context beyond what annotations state.
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?
Long but every paragraph earns its place: core behavior first, then wait/front semantics, then edge cases and long-render polling guidance. The structure is scannable and the wording is dense without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides the full return contract, including failure and queued responses. It also tells the agent what to do when the pipeline times out and where prompt_id can be recovered after an interrupted session. For a 9-parameter tool with side effects, the contextual surface is fully covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains wait, roll_seeds, allow_invalid, confirm_spend, return_preview, front, save_dir, and timeout_seconds. workflow_id is the sole obviously-nameable parameter and does not need elaboration, so the coverage is nearly complete.
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?
Uses a clear verb+resource pair ('Queue the workflow') and then enumerates exactly what it returns (status, node errors, output file refs, data_outputs, inline preview thumbnail). It also explicitly separates itself from view_output and get_run_status, so an agent can distinguish it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete conditional guidance: use wait=False for long renders, poll with get_run_status, save with save_output, pass return_preview=False when no image input is needed, set confirm_spend=True only after explicit user agreement, and allow_invalid only when local validation can be lax. It even names the alternative tools and the scenarios that select them.
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 discloses behavior well beyond the annotations: operations apply in order, a failing operation stops the batch with the graph unchanged past that point, and widget values and link types are checked live with a 'force' override. It also states the result shape as a compact delta versus the full graph via summary, so the agent knows what to expect.
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 dense but well structured, using a literal list for operation shapes and clearly separated notes for ordering, virtual classes, force behavior, failure semantics, and result. It contains no filler and every sentence adds a load-bearing detail for calling the tool correctly.
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 complex editing tool with an output schema, this description covers operation formats, failure atomicity, override behavior, ordering relative to sibling tools, naming sources, virtual node requirements, and return options. Nothing needed to invoke the tool correctly is missing.
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 no schema-level parameter descriptions, the description carries the full semantic burden and compensates strongly: it documents each operation dict, the definition_id variants, set_group and position fields, mode codes, virtual node classes, and summary behavior. The only parameter left implicit is workflow_id, but its name and required type make its purpose self-evident.
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 immediately states a clear action and resource: 'Apply batched edits' to a workflow, then enumerates every supported operation type. It also distinguishes definition-scoped operations from top-level edits by naming the definition twins, so an agent can tell exactly what the tool does and how its variants relate.
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 gives concrete routing and ordering guidance: layout/group ops should run 'AFTER' organize_workflow, slot/widget names come from get_node_info, and full-graph queries belong to inspect_workflow. It also explains the difference between top-level and definition-scoped operations, which tells the agent which variant to choose in which context.
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