ComfyPilot

Server Quality Checklist

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

Latest release: v1.9.0
Disambiguation2/5
Multiple tools have overlapping purposes: comfy_get_status and comfy_describe_dynamics both return combined status snapshots; comfy_get_system_stats, comfy_get_gpu_info, and comfy_check_vram all report VRAM; comfy_list_extensions and comfy_list_installed_nodes both list installed nodes; comfy_get_model_info and comfy_get_node_info both return node schemas; and comfy_apply_template is an explicit alias for comfy_build_workflow. While descriptions are detailed, the boundaries between these tools are blurred.
Naming Consistency4/5
Tools consistently use the comfy_ prefix and mostly follow a verb_noun pattern (list_models, get_queue, delete_history). Minor deviations exist, such as comfy_instance_doctor, comfy_emergency_stop, comfy_auto_snapshot, and comfy_sweep, but these are not chaotic and the pattern remains recognizable.
Tool Count1/5
96 tools is far beyond the well-scoped range (3-15) and even exceeds the 'too many' threshold of 25+. While the server covers many subdomains, the sheer number creates significant cognitive overload and is excessive for a single MCP server.
Completeness3/5
The tool surface is extensive, covering queue management, workflow editing, snapshots, techniques, blueprints, images, models, and environment status. However, there are notable lifecycle gaps: no delete/update for techniques or blueprints, no model deletion or node uninstall, and destinations are only listed without a set/update operation.
Average 4/5 across 96 of 96 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on August 12, 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe-read behavior is covered. The description adds only 'including workflow', which is a slight enhancement but does not disclose behaviors like error handling, payload size, or pagination. It is consistent with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loaded with the core purpose. No filler words or redundant details, which is good. However, the Args repetition is redundant with the schema and could be removed without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with output schema and read-only annotations, the description is serviceable but minimal. It doesn't mention how to obtain a technique_id (e.g., via list/search), what 'full technique data' includes beyond workflow, or any potential size/performance implications. With a richer output schema, the description could be more informative but is not dangerously incomplete.
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 a single required parameter `technique_id` with no description. The description merely reiterates 'The technique ID to retrieve' without adding context like where to find it or what format it expects (e.g., UUID vs. name). Since schema coverage is 0%, the description fails to compensate with additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('full technique data'), and the intent ('for re-use'), making it distinct from listing or searching techniques. However, it does not explicitly differentiate itself from sibling tools like comfy_list_techniques or comfy_export_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a hint of purpose ('for re-use') but provides no explicit guidance on when to use this tool over alternatives like comfy_list_techniques, comfy_search_techniques, or comfy_get_workflow. There is no mention of when not to use it or which sibling tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the annotation readOnlyHint: true. The tool sets a value, which is a mutation, yet the annotation claims read-only. This is a significant inconsistency. Furthermore, the description does not disclose side effects, such as whether the workflow dictionary is modified in place or returns a new instance, nor does it mention required permissions or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the primary action stated upfront. The 'Args' block is structured and avoids redundant wording, though it could be streamlined further by merging the action into a single sentence. It is not overly verbose and each word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic operation but lacks essential context. It does not explain what the tool returns (though an output schema exists), whether it modifies the input workflow in place, or any error conditions. Combined with the annotation contradiction, the description is incomplete for a mutating tool. More detail on expected behavior and side effects is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists each parameter with a brief, human-readable explanation ('workflow: The workflow dictionary', 'node_id: ID of the node to modify'), which adds some clarity beyond the raw schema. However, given the schema has 0% description coverage, the description must compensate more heavily. It falls short by not specifying allowed types or value formats (e.g., 'value' could be any JSON type), and it does not clarify how widget_name maps to actual node inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set a widget value on a workflow node.' It specifies the target resource (workflow node) and the operation (set widget value), distinguishing it from nearby tools like comfy_add_node or comfy_connect_nodes. The name and description align, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or exclusions. For example, it does not clarify whether this is intended for modifying a node's inputs during workflow creation or for runtime updates. Without explicit context, an agent may misuse it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds that it validates basic structure and returns a workflow dict, but does not disclose behavior on invalid JSON or what 'basic structure' validation entails.
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-loaded with the main purpose. The second sentence repeats the verb 'parses' but adds useful detail about validation and return value, so it earns its place overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool, the description with annotations and output schema is mostly adequate. However, it leaves gaps around error handling, what counts as valid basic structure, and any constraints on the workflow JSON, which limits completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden of explaining the parameter. It only repeats that a JSON string is parsed into a workflow dict, without clarifying the expected JSON format, validation criteria, or providing examples. Minimal added meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses a JSON string into a workflow dict and validates basic structure, which is a specific verb+resource. It implicitly differentiates from sibling tools like comfy_import_workflow_from_png by focusing on JSON string input, but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as comfy_validate_workflow, comfy_build_workflow, or comfy_import_workflow_from_png. The description only states what the tool does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the meaningful behavioral nuance of falling back to legacy history when a modern record isn't available, which goes beyond the structured fields. However, it doesn't disclose not-found behavior or what shape the fallback result takes, keeping this at the minimum viable level.
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, front-loaded sentence that places the verb-resource pair first and the fallback clarifier second. Zero filler words, no repetition of the title, and every clause contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation with rich annotations and an output schema, the description is sufficient but leaves gaps: the 'legacy history fallback' mechanism is never explained, and there's no guidance on how job_id maps to modern versus legacy records. It doesn't need to describe the return shape thanks to the output schema, but the fallback semantics should be elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it doesn't. While the single 'job_id' parameter is partially self-evident from its name, the description adds nothing about the expected format, provenance (e.g., from comfy_list_jobs), or how a legacy history ID differs from a modern job ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names the resource ('full modern job record'), and the 'legacy history fallback' note hints at how it differs from plain history reads. However, 'full modern job' is somewhat vague, and it doesn't explicitly distinguish this from nearby siblings like comfy_get_run_result or comfy_get_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The 'legacy history fallback' phrase implies it handles both current and past job records, but there is no statement of when to prefer this over comfy_list_jobs, comfy_get_run_result, or comfy_get_history, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'workflow dictionary to modify' and 'Add a node', implying mutation, while the annotations declare readOnlyHint: true. This is a direct contradiction, making the tool's behavior ambiguous. No additional behavioral details (e.g., in-place vs. return new copy, uniqueness of node_id) are given.
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 front-loaded with the primary action, then lists parameters in a readable format. It avoids fluff, though the 'Args:' labeling could be trimmed for even conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple add-node operation, the description covers the essential behavior and all parameters. However, the contradiction with annotations and lack of usage guidance make it less complete than it could be. The presence of an output schema reduces the need to describe return values.
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 fully compensates by explaining each parameter: workflow (dictionary to modify), node_id (string, with example '8'), class_type (ComfyUI class type), and inputs (optional). This adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add a node to a workflow' with a clear verb+resource. It distinguishes from sibling operations like connect_nodes or build_workflow by focusing on the single action of adding a node with explicit parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not indicate when to use this tool instead of comfy_set_widget_value, comfy_connect_nodes, or comfy_build_workflow. It lacks any exclusions or prerequisite conditions.
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 annotations already establish read-only, idempotent, and non-destructive behavior, so the description only needs to add extra context. It adds that the result is a URL for viewing an image, but says nothing about URL lifetime, accessibility, or behavior for missing files. That is enough for a basic safe getter.
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 a single purpose sentence and a short Args list. The list is slightly redundant with property titles but still earns its place by adding optionality and enum-like values. No filler or repetition beyond that minor overlap.
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, annotated read-only getter with an output schema, the description covers the core purpose and parameter roles. It does not explain when URL retrieval is preferred over sibling comfy_get_output_image, but that gap is largely a usage-guidance issue. Overall, the tool is adequately specified for its 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?
Input schema descriptions are absent, so the Args section is the only semantic documentation. It names all three parameters, marks subfolder optional, and gives valid image_type values ('output, input, temp'), which adds real value beyond the schema; however, the filename and subfolder descriptions are mostly restatements of the parameter names.
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 opening sentence names a specific operation ('Get the URL') and the resource ('an image on the ComfyUI server'), which clearly conveys the tool's function. It does not explicitly contrast with sibling comfy_get_output_image, so it falls short of the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to call this tool instead of alternatives such as comfy_get_output_image or comfy_list_output_images. There are no context cues, prerequisites, or exclusions, so an agent cannot confidently choose between URL retrieval and binary image retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided for this tooliones. The description says 'Get a snapshot's workflow data' and 'Returns: JSON with full snapshot data including workflow', which implies a read operation, but it does not disclose whether restoration has side effects, requires specific permissions, or modifies system state. The tool name suggests 'restore' (implying a write), while the description says 'Get' (implying a read) — this ambiguity is not resolved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one clear line on purpose, one on args, one on returns. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations providedholistically, the description must disclose all behavioral traits. It fails to clarify the nature of 'restore' — does it apply the snapshot or just fetch it? The return is said to include 'full snapshot data including workflow', which implies it's for retrieval, not execution. Yet tool name 'restore_snapshot' (though this is comfy_restore_snapshot) suggests a write operation. It doesn't mention permissions, side effects, or how the returned data is meant to be used. For a tool likely involved in workflow restoration, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (snapshot_id) is defined, and the description states 'The snapshot ID to restore' plus the return includes workflow data. However, the description lacks details about the ID format, how to obtain it (likely from other snapshot tools), and any additional constraints. Since there's only one parameter and the description covers its purpose, this is adequate but not thorough.
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 gets a snapshot's workflow data for restoration, using a specific verb ('Get') and resource ('snapshot'). It differentiates from sibling tools like comfy_snapshot_workflow (which creates snapshots) and comfy_list_snapshots (which lists them), though it doesn't explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need snapshot's workflow data for restoration) but does not explicitly state when not to use it or mention alternatives like comfy_list_snapshots or comfy_diff_snapshots. The 'for restoration' context gives some usage direction but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, and the description aligns with a state-changing operation. It discloses that a JSON confirmation is returned, but does not clarify subscription persistence, duplicate handling, or session scope. With annotations present, the description adds some context but lacks comprehensive behavioral 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?
Description is concise and well-structured: a one-sentence summary, a parameter definition, and a return statement. Every line contributes value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and an output schema exists, so return values are covered. However, the description lacks usage guidelines and any mention of subscription lifecycle (e.g., relationship to comfy_unsubscribe, whether subscriptions persist across sessions), making it incomplete for an agent navigating many related event 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 provides no description for event_type (0% coverage). The description adds examples ('progress', 'error', 'complete') but does not enumerate all valid values or reference where to find them. This gives partial meaning beyond the bare schema, but is not a complete definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Register interest in an event type') with examples of event types. It distinguishes from sibling comfy_unsubscribe by implying the inverse operation, but does not explicitly contrast with comfy_watch_progress or comfy_get_events, so it's not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like comfy_watch_progress or comfy_get_events. It does not indicate prerequisites, typical scenarios, or when not to use it, leaving the agent to infer from the name alone.
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 indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, but the description does not add much beyond stating it toggles a flag. It does not disclose side effects (e.g., whether enabling auto-snapshots affects storage or performance) or whether the toggle persists across sessions. The description adds minimal context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The Args and Returns sections are minimal but useful. No wasted words, though the Returns section is somewhat redundant given the output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one boolean parameter) and the presence of an output schema, the description is mostly complete. However, it lacks context on when auto-snapshots are useful, how they interact with manual snapshots, or any performance/storage implications. For a toggle tool, this is adequate but not rich.
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%, but the description does explain the 'enabled' parameter as 'Whether to enable auto-snapshots', which adds meaning beyond the schema's bare boolean type. However, it does not clarify edge cases like what happens if the flag is already in the desired state or if there are any prerequisites.
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 toggles automatic snapshot creation on workflow execution, which is a specific verb+resource combination. It distinguishes from siblings like comfy_snapshot_workflow (which creates a snapshot) and comfy_list_snapshots (which lists snapshots) by focusing on the auto-toggle behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you want to enable or disable auto-snapshots) but does not explicitly state when to use this tool versus alternatives like comfy_snapshot_workflow or comfy_restore_snapshot. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's 'Destructive' label adds little. However, it does disclose the confirmation elicitation behavior, which is beyond annotations. No contradiction found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: a one-line summary followed by parameter details. It front-loads the destructive nature and keeps the parameter explanations brief. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and only 2 parameters, so the description is mostly sufficient. However, it doesn't mention what happens after deletion (e.g., irreversibility, impact on related workflows) or any prerequisites. Given the destructive nature, a bit more context would help.
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 explains snapshot_id and confirm parameters, including the default behavior of confirm. This adds meaning beyond the schema's basic type/default info, but could be more detailed about the elicitation process.
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 deletes a snapshot and flags it as destructive. It distinguishes from siblings like comfy_restore_snapshot and comfy_list_snapshots by the verb 'delete' and the resource 'snapshot'.
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 explains the confirm parameter's role in elicitation but does not explicitly state when to use this tool versus alternatives like comfy_delete_history or comfy_clear_queue. It implies usage for deleting snapshots but lacks explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds specific signals it detects (stuck jobs, OOM patterns) and the return structure (stable flag, issues list, queue counts), which is useful but not extensive. It does not contradict annotations, but it also does not disclose limitations or side effects beyond what 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with a clear front-loaded purpose and return summary. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no params, an output schema, and strong annotations, the description covers the essential purpose and return format. However, it lacks guidance on how this fits into a diagnostic workflow, especially with many sibling tools. It does not mention prerequisites or when to prefer this over comfy_get_status or comfy_instance_doctor, making it slightly incomplete in a broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description correctly omits param details since none exist, and schema coverage is 100%. Nothing to add.
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 checks for 'stuck jobs, OOM patterns, and other instability signals' with a specific verb and resource. It distinguishes itself from siblings like comfy_get_status and comfy_instance_doctor by focusing on instability detection rather than general status or diagnostics. The purpose is specific and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like comfy_get_system_stats or comfy_instance_doctor. It states what it does but not when it is the appropriate choice. There is no mention of exclusions or preferred contexts, leaving the agent to infer its use.
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?
Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description adds valuable behavioral context: each endpoint is independent and partial failures are reported without hiding other data, and the environment list is reduced by default to configured/materialized entries. These traits help set expectations about resilience and output size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. The first sentence defines scope, and the second adds crucial behavioral caveats; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool inspects multiple resources and has an output schema. The description covers error isolation and default filtering, providing solid operational context. However, it omits parameter explanations and usage guidance, leaving a few gaps for an agent to infer.
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%, and the description does not explicitly mention `limit` or `configured_only`. The note about default reduction to configured/materialized entries indirectly relates to `configured_only`, but the description fails to define the parameters or their effects clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Inspect' and names concrete resources (Env Manager runtime, node environments, workers), making its scope clear. It distinguishes from generic status tools like comfy_get_status but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus siblings such as comfy_get_system_stats or comfy_get_status. The description gives no usage conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries most of the behavioral burden. The description does not disclose side effects such as whether saving overwrites an existing technique, whether it validates the workflow, or how the technique is stored. It only lists parameters, not behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief and structured with a summary line followed by an Args list. Every sentence contributes value, though the Args explanations could be slightly more informative. It is efficient without being overly terse.
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 save operation with an output schema, the description covers parameter semantics adequately. However, it omits important behavioral context such as overwrite behavior, persistence details, or whether the workflow must conform to a specific format. With four parameters and a nested object, a bit more guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by listing all four parameters with brief definitions: 'workflow dictionary', 'name for the technique', and optional description/tags. This adds meaning beyond the bare schema, but it lacks deeper constraints, examples, or required format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Save a workflow as a reusable technique.' This uses a specific verb ('Save') and a specific resource ('workflow as a reusable technique'), distinguishing it from sibling tools like list_techniques, search_techniques, and replay_technique.
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 purpose implicitly suggests when to use this tool (when you want to reuse a workflow as a technique), but it does not explicitly provide usage context or alternatives. There is no mention of when not to use it or how it differs from related operations like snapshots or imports.
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds that it is a convenience alias, which is a useful behavioral note, but nothing about how the template application works (e.g., whether it validates, what happens on invalid template). With annotations present, the bar is lower, and the description adds some value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using three short paragraphs: purpose, alias note, and Args list. It's front-loaded with the main action, and every sentence adds value. No fluff, appropriate length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple interface (2 params, 1 required) and an output schema (though not detailed here), so the description doesn't need to explain return values. It likely covers the essentials: what it does and the template options. However, it could specify what the output is (e.g., a workflow object) but that's likely in the output schema. With good annotations, this is fairly complete for a convenience wrapper.
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. The description names the 'template' parameter and lists valid values (txt2img, img2img, upscale, inpaint, controlnet), which adds meaning beyond the schema—this is helpful. For 'params', it only says 'Optional parameters to override template defaults', which adds some context but doesn't specify what keys are accepted or any format. Overall, it partially compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Apply a workflow template and return the resulting workflow', which clearly indicates a verb and resource. It also notes it's a convenience alias for comfy_build_workflow, which helps distinguish it from that sibling. However, it doesn't explicitly differentiate from other workflow-related tools beyond that.
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 provides a clear context: it's an alias for comfy_build_workflow, so an agent knows it can use this instead of the longer function. However, it does not mention when to prefer this over other workflow building tools or any exclusions, such as cases where comfy_build_workflow would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe, non-mutating operation. The description adds minor context (returns 'formatted nicely as JSON'), but it does not disclose any additional behavioral traits (e.g., size limits, formatting specifics, or effects on the workflow object). This is acceptable given the annotations, but the description contributes little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the purpose stated in the first sentence. Every word earns its place; there is no fluff or repetition. It is front-loaded with the main action, making it immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with a single parameter and an output schema (present but not shown in the prompt). The description fully captures the return value (JSON string) and the operation's nature (serialization). Given the annotations and output schema, no additional context is strictly necessary. It lacks any mention of edge cases or limitations, but for a straightforward export utility, the description is sufficiently 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?
There is one parameter (workflow) with schema coverage of 0% in the description. The description merely repeats the parameter name and says 'workflow' without explaining the expected structure, required fields, or accepted formats. Since the schema uses additionalProperties: true, the description should clarify what constitutes a valid workflow object, but it does not. The low coverage requires compensation, which is absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: exporting/serializing a workflow to a JSON string. This distinguishes it from siblings like comfy_import_workflow (which loads a workflow) and comfy_snapshot_workflow (which saves a persistent snapshot). The verb 'export/serialize' and resource 'workflow' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., when to export vs. snapshot vs. build). It simply states what it does without contextual hints or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the action without additional behavioral details. Although the annotations declare destructiveHint=true, the description adds no insight into side effects, reversibility, or impact on the queue. It fails to go beyond what the annotation already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no fluff. It is appropriately sized for a tool with no parameters and a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameters, an output schema exists, and the annotations cover safety, the description is minimally complete. However, it lacks differentiation from sibling interruption tools and omits any statement about what happens to the prompt or queue after interruption, which keeps it from being more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and per the rules, a baseline of 4 applies. The description adds no parameter explanation because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (interrupt) and target (currently executing prompt). It differentiates from sibling tools like cancel_run or emergency_stop by focusing specifically on interrupting the active prompt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like comfy_cancel_run, comfy_cancel_jobs, or comfy_emergency_stop. The description offers no context on preferred scenarios or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it uses the v0.20+ canonical jobs API and mentions pagination behavior (offset vs after), which is useful. However, it doesn't describe return format or any rate limits, but with strong annotations, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a one-line summary followed by an Args list. Every sentence adds value. It could be slightly more compact, but it's efficient and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 optional parameters, an output schema, and strong annotations, the description covers the essential behavior (listing jobs with filters and pagination). It mentions the API version and pagination modes. It doesn't explain return values, but the output schema exists, so that's not required. It's complete enough for an agent to use 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 0%, so the description must compensate. It does explain each parameter's purpose (status filter, workflow_id filter, sort_by, sort_order, limit, offset, after) in the Args section. However, it doesn't provide details like valid values for status or sort_by, or the relationship between offset and after beyond a brief note. This is adequate but not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ComfyUI jobs using the v0.20+ canonical jobs API. It distinguishes from siblings like comfy_get_job (single job) and comfy_get_queue (queue state) by focusing on listing jobs with filters. However, it doesn't explicitly contrast with these siblings, so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing jobs with optional filters, but provides no explicit guidance on when to use this tool versus alternatives like comfy_get_queue or comfy_get_history. It mentions the API version (v0.20+) which is useful context, but no exclusions or alternative recommendations.
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 annotations already provide readOnly=false, idempotent=true, and destructive=false, so the core behavioral profile is covered. The description adds a useful validation constraint on the name parameter (must not contain '/' or '..') and clarifies that this is a local save-and-reuse operation, but it does not explain whether an existing blueprint is overwritten, where the blueprint is stored, or any side effects beyond saving.
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 formatted: one summary sentence followed by a clear Args block with short, purposeful explanations. Every sentence has architectural value, no unnecessary detail or repetition. It is easy to scan and understand.
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 four parameters and the nested object type for nodes, the description covers all input parameters and provides essential context. An output schema is present, so the description does not need to document return values. The missing details about node_spec are a small downside, but overall the tool is fully usable from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description carries the entire burden for parameter semantics. Each of the four parameters gets at least one meaningful detail: name has a restriction, nodes is described as a dict of node_id: node_spec, description is for discoverability, and tags are for search/filter. The main gap is that 'node_spec' is left undefined, but the description still adds substantial value 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 opens with a specific action: "Save a set of nodes as a reusable blueprint." This clearly explains what the tool does and conveys the intended result, especially recognizing that publishing a subgraph creates a reusable blueprint. However, it does not explicitly differentiate the tool from sibling tools like comfy_insert_blueprint or comfy_save_technique, so it stops just short of the strongest purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as comfy_save_technique, comfy_export_workflow, or comfy_insert_blueprint. It states the action but gives no context regarding which scenarios call for creating a reusable blueprint, and it mentions no exclusions or alternative tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral details beyond the annotations. It does not mention whether snapshots are immutable, whether it overwrites existing snapshots with the same name, or any side effects. The annotations (readOnlyHint=false, destructiveHint=false) are not contradicted, but no additional transparency is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured. It includes an Args section and a Returns section, with no redundant wording. Every sentence contributes to understanding the tool's purpose, parameters, and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a brief summary of the return value ('JSON with snapshot id, name, timestamp, and node_count') but omits details such as the expected format of the workflow dictionary or any potential constraints. It is adequate for a simple create operation but lacks some context that could be useful for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for each parameter: 'workflow: The workflow dictionary to snapshot' and 'name: Optional name for the snapshot.' This goes beyond the bare schema by explaining what the parameters represent, though it could further elaborate on the structure of the workflow dictionary if needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a snapshot of the current workflow state.' This distinguishes it from other snapshot-related tools like list_snapshots, diff_snapshots, restore_snapshot, and delete_snapshot, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool relative to alternatives. It lacks context such as 'Use this before making changes to the workflow' or 'For automatic snapshots, use auto_snapshot instead.' No exclusions or preferred scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds the scope 'all installed' but does not disclose additional behavioral details such as whether it scans system directories or relies on cached data. It is consistent with the annotations, so no 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 entire description is a single sentence of 9 words, directly stating the action. It is front-loaded with the verb and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with an output schema and strong annotations, the description is sufficient. It clearly indicates the scope of the listing, and the output schema covers the return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The schema is empty with 100% coverage, and the description correctly implies no arguments are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'all installed ComfyUI custom nodes and extensions', which is clear. However, the existence of a sibling tool 'comfy_list_installed_nodes' creates potential ambiguity, as the description does not distinguish between this tool and that one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or references to other tools such as comfy_list_installed_nodes or comfy_list_node_types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds only parameter labels and does not clarify whether the workflow is mutated in place or a new workflow is returned, nor whether connections are validated. This is a modest addition 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 a one-sentence purpose followed by a compact Args list. Every line earns its place and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering safety, the description is mostly sufficient for a simple connection operation. However, it omits usage context and mutation semantics, which are important for a tool that manipulates workflow structure.
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%, but the Args section defines all five parameters with meaningful roles: workflow dictionary, source node ID, output index, target node ID, and target input name. This compensates well for 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 opening sentence 'Connect two nodes in a workflow' uses a specific verb and resource, clearly stating the tool's function. It is easily distinguished from sibling tools like comfy_add_node or comfy_set_widget_value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as comfy_build_workflow, comfy_add_node, or comfy_validate_workflow. It also lacks any exclusions, prerequisites, or context about typical workflow-building sequences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=trueament, idempotentHint=true, destructiveHint=false, so the operation is known to be safe. The description adds that it returns a JSON with specific fields (added_nodes, removed_nodes, modified_nodes, total_changes), which is useful. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose. It includes an Args section and Returns section, which is well-structured. No fluff, but the param descriptions are minimal (just names), which could be improved but does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the return types don't need to be fully described. However, the description doesn't explain the exact semantics of parameters (e.g., what if both id_b and current_workflow are set? What if only id_a? What does 'modified_nodes' mean?). The tool is relatively simple, but the param semantics gap makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and while the description provides a brief args list, it doesn't add meaning beyond what the schema already includes (id_a, id_b, current_workflow). It doesn't explain formats, constraints, or how to choose between id_b and current_workflow. The description only lists names, similar to the schema titles, so minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it diff two snapshots or a snapshot vs current workflow, using specific verbs ('Diff') and specifying the resources (snapshots and workflow). It distinguishes from siblings like comfy_snapshot_workflow and comfy_restore_snapshot by focusing on comparison, not creation or restoration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it can compare two snapshots or a snapshot against the current workflow. It implies when to use it (for comparing states), but does not explicitly state when not to use it or suggest alternatives. However, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe, read-only nature is covered. The description adds that it 'Returns structured RunResult', which hints at the output type but not the internal structure or behavior (e.g., how results are stored, latency). With annotations handling safety, the added value is minimal but not contradictory. Score 3 reflects that the description provides slight extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a one-sentence purpose, a note on the return type, and a clean Args list. There is no wasted text, and the essential information is front-loaded. It earns a perfect score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema, the description covers the basics. However, it does not differentiate from sibling tools like comfy_get_history or comfy_get_job, which might also return execution details. It also does not mention potential failure cases (e.g., invalid prompt_id) or prerequisites (e.g., prompt must have been executed). While not severely incomplete, it leaves gaps that a richer description could fill for a tool in a large toolbox.
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 must compensate. It does explain that prompt_id is 'The ID of the prompt execution to retrieve', providing a clear semantic meaning beyond the schema's bare 'Prompt Id' title. This is sufficient for a single-parameter tool, though it could expand on how to obtain a prompt_id or format expectations, but the current explanation is adequate.
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 'Get result of a specific prompt execution', specifying the verb 'Get' and the resource 'result of a specific prompt execution'. This distinguishes it from sibling tools like comfy_get_queue or comfy_get_history, which serve different purposes. The inclusion of 'specific' and the parameter prompt_id makes the scope precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit guidance on when to use this tool versus alternatives. It does not mention that this should be used after a prompt has been executed, or contrast it with comfy_get_history or comfy_get_job. Usage context is only implied from the purpose, leaving the agent to infer the appropriate timing and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it returns combined status JSON with queue info, system stats, and event health, which is useful but doesn't go beyond what the annotations and output schema likely cover. 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 extremely concise, with a single line summarizing the purpose and a brief bullet list of return contents. Every word earns its place, and it's front-loaded with the key phrase 'one-shot status overview'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is complete enough. It lists the three main components of the return value (queue, GPU, execution state, events) and notes it's a combined JSON. The only minor gap is not specifying the exact structure, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to clarify. The description correctly focuses on the return value, which is the only meaningful input for the agent. With no parameters, the description doesn't need to compensate for schema gaps, and it adequately explains what the output contains.
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 provides a 'one-shot status overview' covering queue, GPU, execution state, and events. It distinguishes itself from siblings like comfy_get_system_stats and comfy_get_gpu_info by combining multiple aspects into a single status call, though it doesn't explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a quick, comprehensive status check, but it doesn't explicitly state when to use it versus more specific tools like comfy_get_system_stats or comfy_get_queue. The 'one-shot' phrasing suggests it's for a broad overview, but no explicit guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, and the description reinforces this by stating 'Upload an image to ComfyUI,' implying a write operation. It adds useful detail about the 'subfolder' parameter (optional directory placement) and 'overwrite' flag (defaults to false), but does not discuss authorization requirements, storage limits, or any side effects beyond file creation. 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 extremely concise: a one-line purpose and a clean Args block for four parameters. No fluff, no redundancy with the schema, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential operation but omits context like return value (what happens on success—does it return a URL, a path?), error handling, and prerequisites (e.g., ComfyUI must be running). Since the schema includes a title and required fields, it's not incomplete, but it lacks operational details that could prevent misuse. Among a large set of comfy_* tools, this one's scope is narrow and largely self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a brief explanation for each parameter, but lacks specifics like allowed image formats, maximum file size, or filename constraints. The schema itself has no parameter descriptions (0% coverage), so the description fills that gap but doesn't go into detail. For example, it doesn't clarify whether image_data must be base64-encoded data URI or raw base64, or what subfolder structure is expected.
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 is concise and specific: 'Upload an image to ComfyUI' clearly identifies the action (upload), the resource (image), and the destination (ComfyUI). It distinguishes from sibling tools like comfy_get_artifact (retrieval) or comfy_queue_prompt (execution), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternativesholistically. It doesn't mention when not to use it, nor does it reference related tools like comfy_import_workflow or comfy_download_model. The context of uploading an image is clear, but exclusions or alternative suggestions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds the v0.26+ version requirement and legacy fallback, which is a useful behavioral detail. However, it does not explain the fallback mechanism, side effects, or prerequisites, leaving some ambiguity for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the action, scope, and version. No unnecessary words or repetition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the core function and scope. It leaves the 'legacy fallback' ambiguity unexplained, but the essential behavior is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides essential context that job_ids refers to the running or queued jobs to cancel. It gives meaning beyond the schema's bare 'Job Ids' title, but does not detail expected format, count, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Cancel') with a clear resource ('multiple running or queued jobs') and adds version context. It distinguishes itself from sibling tools like comfy_cancel_run (single job) and comfy_clear_queue (clears entire queue) by explicitly stating 'multiple'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for canceling multiple jobs but does not explicitly state when to use it instead of alternatives like comfy_cancel_run or comfy_interrupt. There is no when-not guidance or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds context that it affects 'running or queued' prompts, clarifying the scope beyond just 'cancel'. This adds behavioral detail not present in annotations alone, though it doesn't discuss irreversibility or effects on dependent operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear first sentence stating the action and an Args section. No filler words, front-loaded with the main purpose. However, it is slightly sparse, lacking any additional usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, output schema, and low complexity, the description is reasonably complete. It could mention that cancellation is permanent or what happens if the prompt is already finished, but overall it's adequate for a straightforward cancel operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides a basic explanation for prompt_id ('The prompt ID to cancel'), adding minimal meaning beyond the schema. It clarifies the parameter's purpose but lacks detail about format or how to obtain the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Cancel a running or queued prompt by ID', which is a specific verb+resource. It clearly distinguishes from similar sibling tools like comfy_cancel_jobs (jobs vs prompts) and comfy_interrupt (general interrupt vs specific prompt cancellation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for canceling a specific prompt by ID but does not mention when to use it over alternatives like comfy_cancel_jobs or comfy_clear_queue. No explicit when-not-to-use guidance or contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint: true and destructiveHint: false, so the description doesn't need to repeat safety implications. The description does add detail on the two actions (unload models, free memory) which aligns with annotations (no contradiction). However, it doesn't discuss side effects like whether unloaded models need reloading, which could be relevant but is not critical for a safe, idempotent operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: a single purpose line followed by a two-line Args list. It is front-loaded with the main action, uses no filler, and every sentence adds value. Perfect structure for quick agent scanning.
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 two-boolean tool, the description fully explains what each argument does and the overall action. The existence of an output schema (not shown) likely covers return values. The only minor gap is that it doesn't mention any preconditions (e.g., whether models must be loaded) or post-conditions, but these are not essential for an idempotent cleanup operation.
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 types and defaults (booleans with default 0), while the description adds meaning for each parameter: 'unload_models: Unload all loaded models from VRAM' and 'free_memory: Free cached memory allocations'. This clarifies what true values do, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Unload models and/or free VRAM memory.' This is a specific verb-resource combination (unload models, free memory) that distinguishes it from sibling tools like comfy_check_vram (which checks) or comfy_emergency_stop (which stops execution). The title 'comfy_free_vram' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., comfy_check_vram, comfy_restart, comfy_emergency_stop). It only states what the tool does, without context for selection or any exclusions. With 90+ sibling tools, this lack of decision support is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return type (image content block) and the download aspect, but it doesn't disclose error handling, file availability, or network dependencies. This is consistent with annotations and adds a bit of context, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the main purpose stated in the first line and parameter details in a compact Args block. Every sentence adds value, and it is front-loaded with the key action and return type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (two parameters, no output schema), the description covers the essential purpose and return type. It doesn't fully explain edge cases like missing files or nested subfolder behavior, but the annotations and simplicity mitigate the need for extensive documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning to the parameters. It provides an example filename and notes that subfolder is optional, which goes beyond the schema's bare type and title. However, it doesn't explain constraints, how to locate images, or relationship to other tools, so it's minimal coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download an output image from ComfyUI') and the outcome ('return it as an image content block'). It distinguishes this from siblings like comfy_get_image_url (which returns a URL) and comfy_list_output_images (which lists images) by specifying the return format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an actual image content block is needed, but it does not explicitly mention alternatives or exclusions. It lacks guidance on when to prefer this over comfy_get_image_url or comfy_download_batch, so the agent must infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context by noting that both destinations and their paths are returned, but it does not explain what 'configured' means or whether the list is dynamic. 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 a single, front-loaded sentence with no filler or redundant elaboration. Every word adds meaning, making it optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only list operation with zero parameters, a provided output schema, and strong annotations. The description sufficiently conveys the core purpose and mentions paths, which is the primary return content. It could add a bit more context about what 'destinations' refers to (e.g., disk, TD, Blender), but the output schema and sibling tools provide enough surrounding context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The description adds no parameter meaning, but none is needed. Per the rubric, 0 params yields a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and the specific resource ('configured output destinations'), and adds that it returns their paths. This distinguishes it from sibling tools like comfy_list_output_images (which lists images, not destinations) and the send_to_* tools that consume destinations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios such as before sending outputs, inspecting current configuration, or how this relates to sending tools. The description simply states what it does without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds the 'local filesystem fallback' behavior, which is useful context, but does not detail when the fallback triggers, how results are sorted, or any limitations. Minimal additional behavioral disclosure beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences and a short arg list. The main purpose is front-loaded, and every word adds value. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and annotations, the description is fairly complete. It indicates the source (history) and a fallback, but lacks details on fallback conditions and any ordering/pagination behavior. Still, it is sufficient for a straightforward listing operation.
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 must compensate. It does: 'subfolder: Optional subfolder to filter by' and 'limit: Maximum number of filenames to return' provide clear meanings for both parameters, though not deeply detailed. This adequately fills the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists output images from history with a local filesystem fallback. This distinguishes it from comfy_get_output_image (which retrieves a single image) and other listing tools like comfy_list_models. The verb+resource+source is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. It mentions 'history with a local filesystem fallback' but does not explain when fallback occurs or when to prefer this over comfy_list_artifacts or comfy_list_models. No alternatives or exclusions are provided.
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 read-only, idempotent, and non-destructive behavior. The description adds details about walking the workflow, finding output nodes, and returning the largest matching timeout plus the node that drove the decision, providing meaningful extra behavioral transparency 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 concise and well-structured, with a clear overview, context, behavior, and a short Args section. It contains no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives enough context about the default timeout and the return value (largest matching timeout plus node) even without an output schema. It covers the essential purpose and expected result, making it reasonably complete for the simple 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?
There is only one parameter (workflow) and the schema treats it as a generic object with additionalProperties true. The description clarifies it is an 'API-format workflow dict,' but does not detail any required fields or structure. This is partial semantic guidance but not comprehensive given the loose schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recommends an HTTP timeout based on output nodes. It mentions the default ComfyPilot timeout and the motivation for exceeding it, but does not explicitly differentiate from similar siblings like comfy_recommend_runtime or comfy_set_limits, so the purpose is specific but not fully distinguished.
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 explains when the default timeout is insufficient and what the tool does, but does not explicitly state when to use this tool versus alternatives. It provides context but lacks a clear 'use this when' directive.
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 convey readOnlyHint=false and destructiveHint=false, so the mutation aspect is known. The description adds that it returns a JSON confirmation, but it does not disclose potential errors for invalid event types or the reversibility of the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three clear sections: a one-line purpose, an Args specification, and a Returns note. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema, the description covers the essential aspects: action, parameter, and return type. It lacks deeper usage context or edge-case behavior, but those are minor gaps given the tool's 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 description coverage is 0%, and the description's Args section provides a minimal clarification: 'event_type: The event type to unsubscribe from'. This is self-evident from the parameter name but adds a little relational context. No accepted values, format, or examples are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('subscription to an event type'), making the purpose unambiguous. It clearly distinguishes from siblings like comfy_subscribe (opposite action) and comfy_get_events (listing events).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The inverse relationship to comfy_subscribe is implied by the tool name and sibling list, but the description doesn't state prerequisites or edge cases like unsubscribing from an already-removed event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description only needs to add value. It does so by specifying the return format ('JSON with embeddings list and count'), but does not disclose any other behaviors like pagination or filtering. This is adequate for a simple list but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two short sentences, front-loaded with the core action and return format. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list operation with an output schema, the description is complete. It states exactly what is listed and the response shape. There are no complex edge cases, prerequisites, or alternatives to document.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is vacuously 100%. The description does not need to explain parameters, but it also doesn't add any parameter-related detail. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'available embeddings,' clearly identifying the tool's function. It distinguishes from sibling list tools like comfy_list_models or comfy_list_extensions by the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or when not to use it. It simply states the action without any context, leaving usage to be inferred. No exclusions or alternative tool mentions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, idempotentHint true, destructiveHint false, so the description does not repeat those. It adds value by specifying that the queue state includes running and pending prompts, which is behavioral. However, it does not elaborate on whether the response includes ordering or limits, but given high annotation coverage, this is acceptable. No contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys all necessary information. It is front-loaded with the main action and provides minimal waste. Every word contributes to understanding the tool's purpose 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?
Given the simplicity of the tool (0 params, clear annotations), the description is sufficiently complete. The presence of an output schema means the description need not explain return values, but it does mention the key output element. It could mention if the queue includes per-item details or just summaries, but overall it is adequate. The sibling names suggest various tools, so the need to differentiate is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, so the schema provides no parameter information. The description adds meaning by clarifying the return includes running and pending prompts, which is sufficient. Baseline for 0 params is 4 as per rubric, and the description uses that to add context effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current queue state including running and pending prompts' clearly states the purpose with a specific verb and resource. It distinguishes this tool from siblings like comfy_list_jobs and comfy_get_status by focusing on the queue state, though it could be more specific about what queue state entails (e.g., counts, IDs, positions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the user needs to check the queue state, but it does not explicitly contrast with sibling tools like comfy_list_jobs (which may list individual jobs) or comfy_get_status (which may be broader). It provides no 'when not to use' guidance, but the phrasing 'current queue state' gives a clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the open-world nature (public hub) and the source options, but doesn't disclose details like rate limits, pagination, or result format. With annotations covering the core safety traits, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose followed by a clear Args list. Every sentence adds value, no fluff. The examples for query are particularly helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 params, 1 required) and has an output schema, so the description doesn't need to explain return values. It covers the key usage aspects: query format, source options, and limit constraints. Slightly more detail on result ordering or error cases would push it to 5, but it's complete for the tool's complexity.
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 must compensate. It does: explains query with examples, source with allowed values, and limit with range (1-50) and default. This adds meaning beyond the bare schema, though it could be more detailed about result ordering or filtering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a public model hub for models matching a query, with specific examples. It distinguishes from siblings like comfy_search_models (which likely searches local models) by specifying 'public model hub' and the source parameter (huggingface/civitai).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use it (searching public hubs) and implies alternatives exist (e.g., comfy_search_models for local models). It doesn't explicitly state when not to use it, but the 'public model hub' qualifier and source options give sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey mutation (readOnlyHint=false) and non-destructiveness. The description adds that it updates warn/block thresholds, max queue depth, and timeout, and returns JSON with updated values. It does not disclose persistence, immediate effect, or scope of the change, so some behavioral ambiguity remains.
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 scannable: a one-sentence purpose followed by a labeled Args section and a Returns line. Every sentence adds useful information, and no filler is present.
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 4-parameter configuration tool, the description covers purpose, all parameters, defaults, and return behavior. It lacks when-to-use guidance and some context about how long settings persist or whether they apply globally, but an output schema exists and the core usage is well supported.
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 carries full responsibility for parameter meaning. It fully delivers: each of the four parameters maps to a plain-language explanation and a default value (e.g., warn_pct=80.0, block_pct=95.0). This is exactly the compensation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update VRAMGuard safety thresholds,' which clearly names the action (update) and the resource (safety thresholds). It distinguishes this from sibling monitoring/recovery tools like comfy_check_vram or comfy_free_vram by framing it as configuration rather than inspection or mitigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or warnings. The description only states the action and parameters, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (all hints false match the mutating nature of 'Set favorite status') and adds useful details like the rating sentinel '-1 to leave unchanged' and default behaviors. However, it doesn't address side effects, validation outcomes (e.g., invalid technique_id, out-of-range rating), or idempotency implications, which matter given idempotentHint is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly efficient: one purpose sentence followed by a clean, standard Args block with no filler or repetition. Every line earns its place, and the format is immediately scannable.
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 3-parameter mutation with an output schema and no enums or nested objects, the description covers the essentials well: what it does and what each parameter means. It's slightly light on edge-case behavior (e.g., what happens with rating=0, or calling repeatedly), but for the scope of this tool, the coverage is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by documenting all three parameters with meaning and default semantics. The explanation of rating's '-1 to leave unchanged' sentinel and favorite's 'default True' provides genuine clarity an agent needs; a small deduction for not elaborating further on valid ranges or interaction effects between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Set favorite status and/or rating for a technique,' clearly identifying the action (set favorite/rating fields) and the target resource (a technique). This cleanly distinguishes it from siblings like comfy_save_technique, comfy_list_techniques, and comfy_search_techniques, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through the semantic description and parameter docs rather than stated explicitly. There is no guidance on when to choose this over related siblings (e.g., comfy_save_technique) or when-not-to-use it, but the purpose is clear enough that an agent could reasonably infer when to call it.
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 greatly expands on the annotations by revealing path-resolution restrictions: absolute paths, '..' traversal, and symlink escapes are rejected. It also discloses that inline bytes are opt-in and capped at 25 MiB, giving the agent valuable safety- and limit-related behavior beyond the readOnlyHint/idempotent 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 short, front-loaded, and every sentence carries useful information. It avoids fluff and jargon while communicating key behavioral constraints in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters and no schema parameter descriptions, but the description only fully covers relative_path behavior and vaguely mentions inline bytes. It provides good security context and core purpose, but an agent would still need inference about include_data, include_sha256, and max_inline_bytes handling. The existence of an output schema helps but does not compensate for incomplete parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It meaningfully explains relative_path resolution and mentions the inline bytes cap, but it does not connect include_data to base64 bytes, explain include_sha256, or clarify how max_inline_bytes relates to the stated cap. Optional parameters are left underspecified.
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 action ('Get') and explicit resource ('metadata ... for one output file'), clearly stating the tool's purpose. It also distinguishes itself from list/download siblings by scoping to a single file and emphasizing metadata/bytes retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (one output file, metadata, optional bytes) but does not provide explicit when-not-to-use guidance or name alternative tools such as comfy_list_artifacts, comfy_get_output_image, or comfy_download_batch. Usage context is clear enough, but alternative selection guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint (false). Description adds no behavioral nuance beyond listing returned data (torch version, device names). It doesn't mention potential latency or prerequisites.
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?
One sentence, front-loaded with the main purpose, and lists expected information. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations (readOnly, idempotent) and no parameters, the description captures the essential info. Mentions specific fields, making it complete for a simple read 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?
No parameters exist, so description has nothing to add beyond schema. Baseline 4 applies because the tool is parameterless and the description correctly focuses on returns.
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?
Clear verb+resource: 'Get detailed GPU info' with explicit data points (VRAM, torch version, device names). Distinguishes from siblings like comfy_get_system_stats (system-wide stats) and comfy_free_vram (mutational).
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?
Implied usage—natural for when you need GPU-specific information. No explicit comparison to alternatives like comfy_get_system_stats or comfy_check_vram, but the scope is self-evident. No when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description does not need to repeat them. The description adds no extra behavioral context beyond what annotations provide, which is acceptable 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 a single, succinct sentence with no redundancy or unnecessary detail. It effectively conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, straightforward output), the description is complete. It mentions the key data returned and the structured nature of the result.
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?
The tool has no parameters, so there is nothing to describe. This is trivially 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?
The description clearly states the action (Get), the resource (ComfyUI system stats), and specifies the contents (OS, GPU, VRAM, version info). It unambiguously distinguishes this tool from siblings that might target other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like comfy_get_gpu_info. The description implies usage for retrieving system stats but does not explicitly mention when not to use it or point to more specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description need not restate those. It adds value by explaining that results are normalized and V1/V3 transparent, and by clarifying the distinction between widget_inputs (is_link_target=False) and link_inputs. This gives useful behavioral context beyond the safety 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?
The description is well-structured with a purpose line followed by explicit 'Returns:' and 'Args:' sections. Every element contributes necessary information without redundancy or filler, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 inspection tool, the description covers purpose, parameter semantics, and return structure in adequate detail. The output schema exists, so deeper return value documentation is unnecessary. It does not mention edge cases like unknown node types, but that is a minor gap for such a 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 only provides the parameter name and type; the description adds the line 'node_type: The node type name to inspect' and the return section indicates it expects a class name. This provides some semantic meaning beyond the schema, but it is still relatively terse and could benefit from examples or clarification of what counts as a node type name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get widget/input details for a node type' and enumerates the return fields (node_type, inputs, widget_inputs, link_inputs), making the tool's function very clear. It distinguishes itself from siblings like comfy_get_node_info by focusing specifically on widget/input details.
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 this tool is for inspecting widget/input details, but it does not explicitly state when to use it versus alternatives such as comfy_get_node_info or comfy_list_node_types. No exclusions or alternative guidance is provided, leaving usage context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context beyond annotations by noting that installation goes through Comfy Manager and the underlying command. However, it does not disclose side effects like network access, environment mutation, or what happens when confirm is false or omitted—important for an installation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a clear one-line summary, useful implementation detail, concrete examples, and a short argument list. Every sentence earns its place with no 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 moderately complex install tool with an output schema, the description covers the core semantics, package naming conventions, and CLI foundation. It could mention prerequisites or alternative tools, but the available annotation context and output schema reduce the burden on the description.
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%, but the description compensates by naming and explaining all three parameters: name, workspace, and confirm. It adds meaning beyond the bare schema, though it could be more explicit about defaults or interactions between confirm and the CLI behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Install a custom node') and gives the exact CLI command used (`comfy node install <name>`). It also provides concrete name-format examples, making the tool's purpose and scope unambiguous and differentiating it from install/workflow-dependency siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys useful context such as using Comfy Manager and typical GitHub-slug naming, but it does not explicitly say when to prefer this tool over alternatives like comfy_install_workflow_deps or comfy_list_installed_nodes. No when-not-to-use guidance is provided.
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 value beyond the annotations by disclosing the validation timing ('selector is checked immediately before the mutation') and the behavioral guarantee about not falling back to port 8188. These details enrich the destructiveHint/idempotentHint annotations without being redundant. Slightly short of 5 because 'safely' is never explicitly defined (e.g., graceful shutdown behavior).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three crisp sentences with key information front-loaded. The critical first sentence states the purpose clearly. The only minor inefficiency is the slightly awkward 'First call...' mid-paragraph construction, but overall there is minimal waste and strong scannability.
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 destructive, non-idempotent-free operation with 5 params, the description covers the safety selector flow (doctor → pass back ID) and port behavior. However, it omits what triggers the timeout, what wait_for_health verifies, and the state of running jobs on restart. Given the output schema exists, return values need no explanation, but the operational semantics could be richer for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description bears the full burden of parameter explanation. It meaningfully addresses 2 of 5 parameters: expected_instance_id and expected_pid map to 'pass back either its instance_id or listener PID.' However, confirm, timeout_seconds, and wait_for_health are entirely unexplained, leaving the agent to guess their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Safely restart the selected local instance through Manager V2.' — specific verb (restart) + resource (selected local instance) + mechanism (Manager V2). The additional detail that 'ComfyPilot never falls back to launching a competing server' clarifies the tool's scope and differentiates it from sibling lifecycle tools like comfy_launch_server, comfy_stop_server, and comfy_interrupt.
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 an explicit prerequisite workflow: 'First call comfy_instance_doctor and pass back either its instance_id or listener PID.' This names a specific sibling tool as a precondition. However, it doesn't fully cover when to use this over alternatives like comfy_emergency_stop or comfy_launch_server, leaving some exclusion logic implied.
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 readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: checkpoint family detection from params, auto-detection from first installed checkpoint, fallback to SD 1.5 when undetermined, and dispatch to family-specific builder. This enriches the agent's understanding of routing behavior without contradicting 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every section serves a purpose: the intent-by-family list is necessary for routing, and the Args section is direct. It front-loads the main purpose and stays well-structured. Slight verbosity in the family routing paragraph could be trimmed, but it's justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple model families, intents, routing logic) and the presence of an output schema, the description covers the essential behavioral context: routing, fallback, and arguments. It doesn't need to explain return values because the output schema exists. The only missing piece is the `family` parameter, which keeps it from a 5.
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 fully carries the burden. It explains `template` with concrete examples and describes `params` as optional overrides with checkpoint-specific routing semantics. However, it completely omits the `family` parameter from the schema, leaving the agent without guidance on that input. This is a clear gap given the absence of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Build a ComfyUI workflow for an intent, routed to the detected model family.' This clearly distinguishes it from sibling tools like validate or apply_template, and the family-routing detail adds unique scope.
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 explains when to use the tool: given an intent and optional params, it builds a workflow routed by model family. It lists supported intents per family, providing clear context. However, it doesn't explicitly name alternatives or state 'use this instead of X', so it stops short of the highest bar.
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, idempotentHint, and destructiveHint, establishing it as a safe read operation. The description adds behavioral detail by specifying the output is a sorted list with node counts, which goes beyond the annotations and provides useful context about the return format.
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 minimal and front-loaded: the purpose is stated in the first sentence, and the return format is given in a concise second sentence. No superfluous information or waste; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless read-only getter with annotations covering safety, the description is complete. It specifies the return content (sorted list with counts) which complements the likely output schema. No further context is necessary for this tool's simplicity.
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 zero parameters, schema coverage is trivially 100%. The description adds no parameter-related meaning because there are none to explain, aligning with the baseline of 4 for 0-parameter tools. It provides sufficient clarity without needing param documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all node categories.' It uses a specific verb and resource, and additionally specifies the return includes sorted list and node counts, which distinguishes it from siblings like comfy_list_node_types (which lists node types rather than categories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as comfy_list_node_types or comfy_search_nodes. There is no mention of contexts, exclusions, or alternatives, leaving the agent without explicit usage direction.
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 read-only, non-destructive, and idempotent behaviorcars. The description adds transparency about the output payload (NodeSchema shape, schema_version, is_output_node) and clarifies the input constraint. Since annotations cover safety, the additional output detail is valuable, though it does not mention any potential side effects (which are likely none given read-only hint).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—two short paragraphs. The first states purpose and output structure; the second clarifies the parameter. It avoids redundancy with the schema but does repeat the parameter name in an Args block, which is minor overhead. Overall clean and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key behavioral aspects: what it returns (detailed node info, output structure), and the only parameter. It aligns with the read-only annotations. It doesn't mention pagination or performance, but that's not necessary for a single-node lookup. Adequately complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter node_type is clearly defined in the Args section: 'The node type name to get info for.' Schema coverage is 0%, but the description explicitly documents the parameter, so the agent understands what to provide. No ambiguity or missing constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed normalized info about a specific node type.' It specifies the exact resource (node type) and the action (get info), and distinguishes it from sibling tools like list, search, and inspect by emphasizing detailed normalized information with a specific output shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single node type but does not explicitly state when to choose this over alternatives like comfy_list_node_types or comfy_search_nodes. It provides no exclusion criteria or direct comparison to siblings, though the specificity of 'get detailed info' offers some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is fully covered. The description adds the 'newest first' ordering and the structured SnapshotList return type, which is moderate value beyond annotations but similar to the calibration baseline for read-only tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Roughly 25 words, front-loaded with the main purpose, with a compact Args block for the single parameter. Every sentence earns its place with no fluff.
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, single-param tool with an output schema and complete annotations, the description captures everything needed: operation, ordering, and return shape. Nothing material is missing given the tool's low complexity.
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%, but the description compensates for the single parameter by explaining that 'limit' is the 'Maximum number of snapshots to return (default 20)', which adds meaning beyond the bare schema field. Fully documents the only parameter present.
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 phrase 'List workflow snapshots (newest first)' provides a specific verb (list), resource (workflow snapshots), and ordering semantics. This clearly distinguishes it from sibling snapshot tools like comfy_snapshot_workflow, comfy_restore_snapshot, and comfy_delete_snapshot.
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 makes the basic operation clear and explains the limit default, so context is implied. However, it never explicitly mentions when to use this over alternatives (e.g., comfy_list_jobs or comfy_auto_snapshot) and offers no exclusions, so it meets only the baseline for guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the mutation aspect is known. The description adds that it returns a QueueAck and mentions parameter behavior (e.g., front insertion) but does not disclose any additional side effects, permissions, or error conditions. It is not contradictory to annotations, but adds limited behavioral context 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 a single concise paragraph with a clear opening statement and an Args list. It is front-loaded with the purpose and then lists parameters efficiently without any unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 6 parameters and nested objects, but has an output schema. The description explains all parameters and the return type (QueueAck), which covers the key usage aspects. It does not go into workflow structure expectations or error handling, but given the output schema and annotations, it is sufficiently complete for an agent to use the tool 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 carries the full burden for parameter meaning. It clearly explains each parameter: workflow (dict to queue), front (insert at front), workflow_id (stable UUID), workflow_version_id (version UUID), partial_execution_targets (output node IDs), extra_data (metadata). This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queues a workflow for execution and returns a structured QueueAck. It uses a specific verb (queue) with a clear resource (workflow), and it is distinct from sibling tools like comfy_validate_workflow or comfy_cancel_run.
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 this is the main tool for submitting workflows for execution, but it does not explicitly state when to use it versus alternatives (e.g., validate first) or mention prerequisites. It gives no exclusion criteria or alternative tool 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?
The description discloses that it enqueues copies, registers with the job tracker, and returns prompt_ids for later monitoring. This goes beyond the annotations (which only indicate non-read-only, non-destructive) to clarify the tool's side effects and interaction pattern, though it does not detail potential resource constraints or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear first sentence and a brief follow-up on use cases and integration. It avoids unnecessary detail and is easy to parse.
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 provides sufficient context for understanding the tool's role, including its relationship to the job tracker and watch_progress. It does not mention validation, error handling, or performance implications, but within the context of sibling tools, it gives enough to select and invoke correctly.
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 description does not adequately explain the parameters. It mentions 'widget' but the args are `node_id`, `param`, and `values`; it does not clarify that `param` refers to a widget name or how `values` maps to the multiple enqueues. The schema provides no descriptions, so the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary function: enqueue multiple copies of a workflow with different values for a single parameter. It also provides concrete use cases (seed, CFG, step, and denoise sweeps), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists scenarios where this tool is useful (sweeps) and mentions integration with the job tracker and comfy_watch_progress. However, it does not explicitly contrast it with alternative tools like comfy_queue_prompt, though the use cases imply when to choose this over them.
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 having destructiveHint=false and readOnlyHint=false, the description adds safety context by stating a hard cap (max_combinations) that will 'Reject the call' when exceeded, preventing runaway operations. It also explains the Cartesian product behavior and the returned grid_shape and assignment map, which are behavioral details not in the annotations. Fails a 5 only because it doesn't mention whether it modifies any state or requires specific 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?
The description is compact and well-structured: a concise summary of purpose, a clear distinction from siblings, a terse example, a structured Args section, and a Returns section. Every sentence provides value without fluff, front-loading the core concept before implementation details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a sweep tool with an output schema: it specifies the required workflow and axes, the tier cap, and the return format (prompt_ids, grid_shape, assignment map). The output schema likely covers exact JSON structure, so the description's brief but sufficient note on returns is acceptable. Loses a point because it doesn't detail edge cases like empty axes lists or validation of axis values, but for typical usage it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite schema coverage being 0%, the description thoroughly explains the purpose of each parameter: workflow as the base API-format workflow, axes as a mapping with format 'node_id.param' -> list of values, and max_combinations as a hard cap with default 64. This adds semantics beyond the bare schema (which only provides types), compensating for the lack of schema descriptions. Not a 5 because it doesn't give examples of valid axes keys or value constraints.
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 performs an 'N-dimensional parameter sweep' over a Cartesian product, with the key difference from comfy_sweep ('varies one widget') explicitly noted. It names the resources (workflow, axes) and outcomes (queued prompts). While it doesn't mention all sibling tools, it distinguishes itself from the most similar one, earning a 4 rather than 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for when to use this tool: when you need to enqueue multiple combinations across multiple axes, contrasted with comfy_sweep for single-axis variation. It implies this is for exhaustive search rather than targeted variations, though it doesn't explicitly state when NOT to use it (e.g., for simple single-axis sweeps). The example (seed x cfg x steps) provides practical 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 indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context by explaining that `confirm` is required to explicitly approve the network download and filesystem write, and that the tool writes to `models/<folder>`. This goes beyond the annotations by clarifying the approval mechanism and the write operation, though it does not detail rate limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It leads with the core purpose and then lists each argument with a brief, relevant explanation. The format is easy to scan, with no filler words or redundant content. Every sentence adds value, making it appropriately sized for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values are handled) and the annotations cover safety/idempotency, the description provides sufficient context for effective use. It covers all parameters, explains the required confirmation, and gives practical examples for folder values. It does not mention error scenarios or prerequisites beyond the CivitAI token, but overall it is complete for a straightforward download operation.
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 must fully compensate. It does: each parameter is explained meaningfully—`url` (direct download URL), `folder` (subfolder under models with common values enumerated), `civitai_api_token` (for gated downloads), `workspace` (optional path), and `confirm` (explicit confirmation). This adds substantial meaning beyond the schema's simple type/title information, though it could be more explicit about defaults and optionality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Download a model via `comfy model download`'. It specifies the action (download), the resource (model), and the exact command, distinguishing it from sibling tools like comfy_download_batch (batch download) and comfy_list_models (listing). The verb and resource are unambiguous, making it easy for an agent to select the correct tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: it specifies that CivitAI links require a `civitai_api_token`, and it lists common folder values (checkpoints, loras, etc.). However, it does not explicitly state when to use this tool versus alternatives (e.g., comfy_download_batch for batch downloads) or when not to use it. The guidance is practical for parameter usage but lacks explicit selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description goes beyond by detailing exactly what is destroyed: 'will cancel all running and pending jobs.' It also explains the confirmation elicitation behavior for the confirm parameter, adding useful context not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief summary, a warning, and parameter explanation. It is concise but has minor redundancy in repeating 'destructive' in both the summary and warning. Overall, each part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description covers the purpose, destructive side effects, and parameter behavior. It does not need to explain return values since an output schema exists. It is complete enough to guide an agent 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?
The schema only provides a boolean with default false, but the description fully explains the semantics: 'If False, the tool asks for explicit confirmation via elicitation before proceeding. Pass True to skip the prompt.' This adds critical meaning and use-case context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's actions: 'interrupt current job, clear queue, and free VRAM.' It uses a specific verb and resource combination, and the phrase 'emergency stop' distinguishes it from siblings like comfy_interrupt or comfy_free_vram.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for emergency situations but does not explicitly compare alternatives like comfy_interrupt or comfy_clear_queue. The confirm parameter guidance is helpful, but it lacks direct exclusions or 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 read-only and idempotent behavior. The description adds meaningful context beyond that: workflow JSON can run arbitrary Python, and the tool surfaces non-stock class_types for security triage. It also explains the trust_level output semantics 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?
Three tightly scoped paragraphs: a purpose sentence, a concise security rationale, and a summary of the return report. Every sentence earns its place with no repetition of annotation fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, when to use it, security motivation, and output report shape. An output schema exists for structural details. It could explicitly exclude sibling alternatives, but for a moderately simple analysis tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one opaque 'workflow' object with no property descriptions and 0% schema coverage. The description identifies it as workflow JSON and mentions class_types, but does not explain the expected node/class_type structure, so the description only partially compensates for the schema's silence.
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 first sentence uses a specific verb 'Enumerate' and a precise resource: 'custom (non-stock) node class types in a workflow.' This clearly distinguishes it from sibling tools like comfy_validate_workflow or comfy_list_node_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool before submitting workflows from untrusted sources, to warn the user or refuse to auto-queue. It does not explicitly name alternatives or list when-not-to-use scenarios, so it stops short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds specific behavioral context: 'case-insensitive substring match on node class_type' and the return format ('JSON with matching history entries'), which goes beyond the annotation hints and is useful for invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: a one-line purpose, a structured Args section, and a Returns line. Every sentence earns its place with no redundancy or filler. The format is ideal for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 params, 1 required) and the presence of an output schema (as indicated), the description is sufficient. It covers the purpose, the parameters, and the return type. It could mention edge cases or the exact structure of returned entries, but since there is an output schema, that is not strictly necessary. Overall, it's adequately complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 full burden. It provides clear semantics for both parameters: query is described as a case-insensitive substring match on class_type, and limit is defined as max matches with a default of 20. This fully compensates for the missing schema descriptions, though it doesn't add extra nuance beyond what's necessary.
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 'Search history for prompts containing specific node types' – a specific verb ('search'), resource ('history'), and scope ('node types'). It distinguishes from sibling tools like comfy_search_nodes (searches node definitions) and comfy_get_history (retrieves history), making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its purpose but does not explicitly state when to use this tool versus alternatives (e.g., comfy_search_nodes or comfy_get_history). There is no mention of exclusions or alternative tools, so guidance is more implied than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds genuine behavioral value by disclosing the matching semantics (case-insensitive substring match) and the response shape (matches list with total count), which goes beyond what the annotations and schema alone convey. No contradiction with annotations was found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core behavior in the first line, followed by a compact standard Args/Returns docstring. Every sentence earns its place: the matching semantics, the two parameters, and the return shape. There is zero filler or redundancy with the structured fields.
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 search tool with an output schema, rich annotations covering safety, and both parameters explained in the description, the tool is well-specified. The description adequately covers search behavior, arguments, and return format. The only minor gap is lack of example usage or pagination details, but given the tool's low complexity this is not a significant omission.
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 compensation burden and does so: it documents 'query: Search query string' and 'limit: Maximum number of results to return', adding meaning beyond the raw schema types. The parameter meanings are clear, though terse—query semantics are self-evident and limit's default of 20 is left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Search for nodes by name' with an explicit qualifier of 'case-insensitive substring match'. This clearly distinguishes it from siblings like comfy_get_node_info (which retrieves a specific node's details) and comfy_list_node_types (which enumerates all node types), making the tool's purpose precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need to find nodes matching a name substring) but gives no explicit when-to-use or when-not-to-use guidance, and does not name alternative tools. Given siblings like comfy_get_node_info, comfy_list_node_types, and comfy_search_hub, there is no clarifying exclusion or pointer to when searching is the right choice versus listing or fetching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is read-only, idempotent, and non-destructive. The description adds 'Poll EventManager' and 'Returns structured WatchProgressFrame', which slightly expands understanding of its behavior, but it doesn't disclose potential edge cases like prompt not found or polling frequency. 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 one sentence plus a parameter list, front-loaded with the primary action and return type. No unnecessary information, perfectly scoped for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple polling tool with one parameter and an existing output schema, the description covers the essential purpose and usage. It doesn't elaborate on polling behavior or alternatives, but given the simplicity and annotation coverage, it's adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description provides a description of the only parameter, 'prompt_id: The prompt ID to watch', which clarifies its purpose. This is helpful, though it doesn't elaborate on how to obtain the ID or its format, but for a single obvious parameter it's sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it polls EventManager for a prompt's execution progress and returns a structured WatchProgressFrame. This verb-resource-purpose combination distinguishes it from sibling tools like comfy_get_status (overall status) and comfy_get_queue (queue listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for tracking a specific prompt's execution progress via polling, providing clear context. It doesn't explicitly state when not to use it or name alternatives, but the purpose is unambiguous enough for an agent to select it appropriately.
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 provides critical behavioral context, notably that events are 'drained' (meaning they are consumed and removed) and that an event_type filter is available. It also explains the return format ('JSON with events list and count'). While annotations don't include readOnlyInfo, the description's clarity on the destructive/consuming nature of the operation is valuable and goes beyond mere schema.
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 terse, informative lines with a clear docstring format. Every sentence provides necessary detail, and the structure (description, args, returns) makes it scannable. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple event-draining tool, the description fully covers behavior, parameters, and return value. The output schema exists so no extra return-format explanation is needed. One could argue for mentioning side effects (events are removed), but 'drain' implies this strongly enough. For a tool with two optional parameters, this is near-complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 0% coverage, the description clearly explains both parameters (event_type and limit), including the default for limit (100). It doesn't add extra detail beyond the schema's own documentation, but for an arguably simple tool, the description effectively covers the parameters. This earns a strong score given the tool's simplicity.
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 verb 'Drain' is specific and memorable, and 'buffered events from EventManager' clearly identifies the resource. While it's not obvious what 'events' refers to without more context about the system, the description effectively distinguishes it from the many sibling tools that perform CRUD operations by emphasizing that this tool retrieves and clears buffered events. It doesn't explicitly name sibling tools for comparison, but the intent is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states this tool 'drains' events, implying it retrieves and clears the buffer—a key usage detail. It also notes optional filters, clarifying its purpose compared to other tools. While it doesn't explicitly state when not to use it or name alternatives, the behaviors are contextually clear given the tool name and description.
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, idempotentHint, and destructiveHint, covering safety. The description adds the version requirement (v0.17+), which is useful operational context beyond what annotations 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 a single, front-loaded sentence with no wasted words. It conveys the key purpose and version constraint efficiently.
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 zero-parameter interface and presence of an output schema, the description is sufficient. It clearly states what the tool does and any version requirements, and the tool is simple enough that no additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the baseline is 4 per the rubric. The description offers no extra parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('enabled ComfyUI features'), with a version note. It distinguishes itself from sibling getters like comfy_get_status or comfy_get_system_stats by specifically targeting features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking enabled features but does not explicitly state when to use it versus alternatives or provide exclusion criteria. It's straightforward enough for the intended purpose, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds transparency by clarifying that the tool returns input/output definitions from ComfyUI's object_info and not model file metadata. This complements the readOnly and idempotent annotations without contradicting them. It gives extra context about the nature of the returned data and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear title, a clarifying sentence, and an Args section with a precise parameter description. It conveys all necessary information without unnecessary verbosity or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's behavior and return value (input/output definition) and distinguishes it from model metadata. While it does not detail output schema or error cases, the existence of an output schema in the MCP definition reduces the need for that explanation. It is sufficiently complete for a simple getter.
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?
The description thoroughly explains the sole parameter 'node_type' with an example ('CheckpointLoaderSimple') and clarifies that it is the node class type to inspect. Although the schema only defines the parameter name and type, the description provides full semantic meaning, effectively covering the parameter's purpose and expected value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get node schema for a model-related node type.' It explicitly distinguishes from model file metadata, making it specific and unambiguous. This differentiates it from sibling tools like comfy_get_node_info or comfy_list_node_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving node schemas of model-related nodes but does not explicitly state when to use this tool over alternatives such as comfy_get_node_info. It lacks direct comparison or 'use this when' guidance, though the mention of 'not model file metadata' provides some boundary.
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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context: it uses ComfyUI's `/models` endpoint to discover folders live and reports the data source ('live' vs 'fallback'), informing callers about the reliability of the result. This goes beyond annotations and is actionable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. Two short paragraphs, three sentences, each sentence earns its place: the first states the purpose, the second explains the mechanism, and the third highlights the data source reporting. No redundancy or fluff.
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 no-parameter tool with an output schema present, the description is complete. It explains the tool's behavior, the live discovery mechanism, and the fallback reporting, which is crucial for interpreting results. There is no missing information needed to invoke or understand the 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?
The tool has zero parameters, so the schema coverage is 100% by default. Per guidelines, a 0-parameter tool gets a baseline of 4. The description adds no parameter-specific information, but it is not needed. The description appropriately complements the empty schema by explaining the data source behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List'), the resource ('every model-folder name'), and the scope ('the connected ComfyUI exposes'). It distinguishes this from sibling tools like comfy_list_models by focusing on folders rather than models themselves. The reference to the `/models` endpoint adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need model folder names) but does not explicitly mention alternatives or exclusion criteria. It lacks guidance on when not to use it or how it compares to related tools like comfy_list_models or comfy_list_destinations. The context is clear, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description need not repeat those. It adds useful behavioral context about pagination (limit, offset) and the return structure (node_types list, total_count, has_more, next_offset), which goes 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 extremely concise: one sentence for purpose, then a simple Args and Returns block. Every sentence contributes value with no fluff or repetition, and the key verb 'List' appears upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with pagination, the description covers the essential behavior: what it lists and pagination parameters. The return structure is specified, and the output schema exists to document exact fields. It omits details like sorting order, but that is not critical for a basic listing 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?
The schema has zero description coverage, but the description explicitly defines limit ('Maximum number of results per page') and offset ('Starting position for pagination'), providing meaning that the schema lacks. This fully compensates for the missing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all available node types with pagination' with a specific verb (List), resource (node types), and scope (all available). It distinguishes from siblings like comfy_list_models (models vs node types) and comfy_get_node_info (specific node vs all types).
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 implies usage for listing all node types but does not explicitly mention when to use this over alternatives like comfy_search_nodes or comfy_get_categories. No exclusion or alternative guidance is provided beyond the implied scope.
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 a safe read-only, idempotent operation. The description adds meaningful context by specifying that it returns 'active' subprocess workers with PIDs, Python versions, and generation, which goes beyond the generic annotation and clarifies the scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with the action verb front-loaded and no redundant information. Every word adds value, making it exceptionally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with an output schema, the description fully specifies the scope ('active workers') and the returned attributes. No additional context is required for an agent to correctly select and invoke the 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?
The tool has zero parameters, so the description does not need to compensate for schema gaps. Baseline 4 is appropriate given the absence of parameters and full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and resource ('active comfy-env subprocess workers') and enumerates returned attributes (PIDs, Python, generation). This distinguishes it from other list tools like comfy_list_models or comfy_get_system_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a monitoring or inspection use case (listing active workers) but provides no explicit guidance on when to choose this tool over alternatives such as comfy_get_status or comfy_get_system_stats. It lacks specific when-to-use or when-not-to-use conditions.
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 readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds that the save is atomic and includes a sidecar manifest, and that prompt_id enriches manifest metadata—useful behavioral context beyond the structured fields. It doesn't mention overwrite behavior or destination paths, but the core side effects are disclosed.
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 efficient: a one-sentence summary followed by a concise Args list. Every sentence adds value, and the main action is front-loaded. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, parameters, and the key sidecar manifest detail. An output schema exists, so return values are already structured. Some destination specifics ('for Blender consumption') are vague, but the description is sufficiently complete for an agent to select and invoke 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?
The schema has no descriptions for any of the three parameters (0% coverage). The description's Args section explains each parameter clearly: filename is 'the image filename in ComfyUI outputs', subfolder is 'optional subfolder in ComfyUI outputs', and prompt_id 'enriches the manifest with history metadata'. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Download image and save for Blender consumption atomically with sidecar manifest.' This uses specific verbs ('download', 'save') and specifies the resource (image) and destination (Blender), distinguishing it from sibling tools like comfy_send_to_disk or comfy_send_to_td.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like comfy_send_to_disk or comfy_send_to_td. It implies usage by mentioning Blender consumption and the sidecar manifest, but no explicit exclusions or alternative comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions atomicity and sidecar manifest, which adds behavioral detail beyond the annotations (readOnly=false, idempotent=true). However, it doesn't elaborate on what 'sidecar manifest' contains or any side effects beyond that. Since annotations already indicate it's not read-only and is idempotent, the description adds some but not extensive insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a one-line purpose and bulleted argument list. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the purpose, parameters, and some behavior (atomic, sidecar). It could mention when to use it over comfy_get_output_image or other send_* tools, but the naming and description make it clear. Given the sibling context, it's adequate.
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?
All three parameters are described clearly: filename (required, from ComfyUI outputs), subfolder (optional, in ComfyUI outputs), prompt_id (optional, for history metadata). Schema coverage is 100% and the description adds meaningful context for each.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: downloading an image and saving it for TouchDesigner consumption, with atomicity and sidecar manifest. This distinguishes it from sibling tools like comfy_get_output_image (which likely just fetches an image) and comfy_download_batch (which downloads multiple files).
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 usage context is implied by the name and description: it's for sending images to TouchDesigner. However, it doesn't explicitly say when to use this over alternatives or when not to use it. The naming pattern (comfy_send_to_*) suggests a family of tools for different destinations, so it's fairly clear, but there's no explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by specifying what is checked (VRAM headroom, queue depth) and what the return JSON includes (safe_to_queue flag, VRAM status, queue counts, issues), which enriches the agent's understanding without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. It uses bullets/headings for the return structure, making it scannable. No wasted words, though it could have explicitly mentioned 'does not modify state' but that's covered by annotations. Overall, efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, straightforward output). With comprehensive annotations and a brief return description, the description is complete enough for an agent to understand what it does and what it returns. The output schema exists, so detailed return formatting isn't required here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (vacuous). Per the rubric, 0 parameters sets a baseline of 4. The description doesn't need to add parameter info, and it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'pre-flight safety check' checking VRAM headroom and queue depth before queueing a prompt. It uses specific verbs and resources, distinguishing it from similar tools like comfy_check_vram or comfy_get_queue by emphasizing its purpose as a pre-queue validation.
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 indicates this is used before queueing a prompt ('Pre-flight safety check before queueing a prompt'), giving clear context. However, it does not explicitly mention alternatives or when not to use it, though among the many siblings, this is fairly obvious.
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?
Beyond the annotations (destructiveHint=true, idempotentHint=true, readOnlyHint=false), the description adds the confirmation behavior: 'If False, the tool asks for explicit confirmation via elicitation before proceeding. Pass True to skip the prompt.' This is critical operational context that annotations do not provide. However, it does not mention potential side effects (e.g., irreversible removal of associated outputs) beyond the generic 'Destructive' label, though the annotation already covers destructive intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences followed by a clear parameter breakdown. It front-loads the purpose immediately ('Delete a specific history entry.') and includes only essential information about the confirm behavior without extraneous detail. Each 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?
For a simple two-parameter tool, the description covers the operation, the parameters, and the confirmation nuance. An output schema exists (not shown) to handle return values, and annotations capture safety traits. No missing information is apparent for the agent to correctly invoke and understand the tool's effect.
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 solely responsible for explaining parameters. It fully explains both: prompt_id as 'The ID of the prompt execution to delete' and confirm with its default behavior and effect on confirmation elicitation. This goes beyond the schema's bare type definitions and provides necessary semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete a specific history entry' with the resource being a specific entry, using the verb 'Delete'. It distinguishes from siblings like comfy_clear_history (which likely clears all) by specifying 'specific', and comfy_get_history/search_history are non-destructive. The purpose is unambiguous and uniquely identifies the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (delete a specific entry) but does not explicitly compare to alternatives such as comfy_clear_history for mass deletion or comfy_search_history for lookup. It lacks explicit 'when to use' or 'when not to use' guidance, falling short of the clarity needed to differentiate choices among siblings.
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 mark the tool as read-only and idempotent, and the description reinforces this by describing an extraction operation. It adds context about the output structure but does not disclose potential errors or performance characteristics, which is acceptable given the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two short paragraphs to cover purpose and output. Every sentence adds value, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's behavior, including both parameter semantics and the distinction between full and summary output. It is sufficient for an agent to know when to call it and what to expect.
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?
Both parameters are described in the tool description: 'workflow' is clearly identified as an API-format workflow dict, and 'summary_only' is explained with its behavior. This compensates for the lack of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: extracting a controllability/dependency surface from a workflow. It specifies the output in terms of controllable widgets, models, embeddings, and output nodes, distinguishing it from sibling tools that manipulate or execute workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent needs to determine workflow parameters without traversing the graph. However, it does not explicitly compare against alternative tools like comfy_inspect_workflow or comfy_validate_workflow, leaving some ambiguity about when to choose this over others.
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, idempotentHint, and destructiveHint, so safety is covered. The description adds useful behavioral context: pagination via limit and the return structure (entries list and total count), which is not in 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?
Two compact sentences plus an Args/Returns structure. Every word earns its place, and the main action is front-loaded. No redundancy or fluff.
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 one-parameter, read-only tool with an output schema and complete annotations, the description covers the essential semantics (limit, return shape, pagination) sufficiently. No critical gaps remain.
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%, but the description explicitly explains 'limit: Maximum number of entries to return (default 20)', providing full meaning beyond the raw schema. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get execution history with pagination' with a specific verb and resource, clearly distinguishing it from sibling tools like search_history or get_queue. The purpose is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance or alternative tools are mentioned. The context implies this is for paginated browsing of full history, but it doesn't contrast with comfy_search_history or comfy_get_run_result, leaving usage somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: it prefers 'prompt' and falls back to 'workflow', and it specifies the return format. This goes beyond annotations and helps the agent understand the extraction logic without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a clear purpose sentence, bullet points for metadata chunks, and a return format note. No unnecessary fluff; each sentence adds value. It could be slightly tightened by omitting the explicit return format since output schema exists, but it's not detrimental.
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 tool with one parameter and an output schema, the description is complete: it covers the extraction mechanism, the two formats, fallback behavior, and the return structure. The output schema provides additional detail, so the description is fully adequate for this straightforward 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?
The only parameter is png_path, and the schema simply says it's a string titled 'Png Path'. The description clarifies it must be an 'Absolute path to the PNG file', which is a meaningful addition beyond the schema. Though minimal, it's sufficient for a single-parameter tool.
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 'Extract a workflow from a ComfyUI-saved PNG's tEXt metadata' — a specific verb and resource. It distinguishes from siblings like comfy_import_workflow and comfy_export_workflow, and the fallback behavior between prompt and workflow formats adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly specifies when to use this tool (when you have a PNG with embedded workflow) and explains the metadata chunks. It does not explicitly mention alternative tools, but the scope is clear and the fallback logic informs the user's expectations. No explicit exclusions, but sufficient 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?
Beyond the annotations (readOnly, idempotent, non-destructive), the description adds key behaviors: history merging for loopback instances and path constraints that prevent escaping the output root. This is valuable operational information not conveyed by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, covering purpose and key behavioral nuances in two sentences without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about history merging and path constraints, but doesn't explain all parameters (e.g., filesystem_fallback) or contrast with sibling tools like comfy_list_output_images.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage). The tool description mentions 'kind' via artifact types (image, video, etc.) and touches on subfolder/path constraints, but does not explicitly explain 'query', 'limit', 'offset', or 'filesystem_fallback'. These parameter names are somewhat self-explanatory, but lacking descriptions for a 6-parameter tool leaves room for misinterpretation.
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 tool's purpose:
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context about loopback history merging and output root constraints, but does not explicitly contrast with sibling tools like comfy_list_output_images or comfy_get_output_image. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds genuine value by explaining the internal intersection mechanism (installed extensions ∩ curated catalog) and clearly documenting the return structure (installed vs. available), which goes beyond the safe-read declaration.
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?
Excellent structure: a focused first sentence stating what the tool does, a second sentence explaining the underlying mechanism and use case, and a clean Returns section documenting the output shape. Every sentence contributes distinct value with no fluff. Marginal deduction only because the vendor list example could be considered slightly illustrative rather than essential.
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?
Complete for this tool's complexity. The catalog-intersection logic is fully explained, the return values (installed and available) are documented, and the output schema reinforces the return contract. With zero parameters, no prerequisites, and a documented output structure, the agent has everything it needs to invoke this correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes 0 parameters, and the rubric establishes a baseline of 4 for this case. The description doesn't waste space on parameters but instead documents the output format, which is the only semantic surface area that exists. The Returns section functionally serves the 100% coverage role that parameter docs would for parameterized tools.
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?
Specific verb+resource+scope: "List partner-API custom nodes installed on the connected ComfyUI" clearly identifies what is listed (partner-API custom nodes) and the context (installed on the connected ComfyUI). The description also distinguishes this from the sibling comfy_list_extensions by explaining it filters through ComfyPilot's curated KNOWN_PARTNER_APIS catalog.
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: "Useful before suggesting workflows that depend on cloud-backed nodes - tells the agent which vendors (Veo, Kling, Seedream, GPT-Image, etc.) are actually wired up on this server." This gives actionable decision-making context. However, it doesn't explicitly name any alternative tool or exclusion cases, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read nature is pre-known. The description adds 'newest first' (ordering behavior) and 'structured TechniqueList' (return shape), which are useful behavioral details beyond annotations. It does not cover failure modes, but for a list operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences plus a one-line args block. No filler. The description is front-loaded with the primary action and includes the parameter explanation in a structured format.
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 listing tool with a simple optional parameter and an output schema, the description provides purpose, ordering, parameter, and return type information. No further context is necessary, and sibling comparisons are not required given the unambiguous action.
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?
The input schema contains only 'limit' with no description, but the description's Args section fully explains it: 'Maximum number of techniques to return (default 50)'. This compensates for the 0% schema coverage and gives the agent the exact parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all saved workflow techniques (newest first)' with a specific verb 'List' and resource 'workflow techniques', and adds ordering detail that distinguishes it from broader listing tools. It does not explicitly compare to comfy_search_techniques, but the 'all' scope implies exhaustive listing, making ambiguity low.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit when-to-use guidance or exclusions. Sibling tools like comfy_search_techniques imply different use cases, but the description relies on common sense. It is otherwise clear for its simple purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it specifies the search scope (name, description, tags) and the default limit. It does not describe return format or pagination, but an output schema exists, lowering the burden. 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 extremely concise and well-structured, with a single-sentence purpose statement followed by a clear parameter list. Every sentence earns its place; no redundant or vague wording. It is front-loaded with the core action and then provides necessary parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with 3 parameters, the description is complete enough: it documents all parameters, the search scope, and the default limit. The output schema exists, so return values need not be described. Annotations cover safety. The only minor gap is explicit usage guidance relative to alternatives, which is already scored under a separate dimension.
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 carries the full parameter burden. It explicitly documents all three parameters: query (text search in name, description, tags), tags (optional filter list), and limit (max results, default 20). This adds meaning beyond the schema's types and defaults, fully compensating for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search workflow techniques by text query and/or tags' with a specific verb (search), resource (workflow techniques), and method (text/tags). This distinguishes it from sibling search tools like comfy_search_models, comfy_search_nodes, and comfy_search_history by explicitly targeting a different resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by the resource type and search mechanism, but provides no explicit guidance on when to use this versus alternatives. There is no mention of scenarios where one should prefer comfy_list_techniques (for listing all) or other search tools, nor any exclusions. This is adequate but leaves the agent to infer context from sibling names.
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 establish the tool is read-only and non-destructive. The description adds significant behavior: the six-pass validation sequence, automatic detection of ComfyUI editor-format, and short-circuiting with a re-export instruction, giving agents a clear mental model of execution.
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, front-loaded with the main action, and uses a clear pass list. Every sentence adds value, and the code-format notation for nodes/links is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the workflow parameter is open-ended (any object), the description covers the essential behavior: validation passes, pre-pass handling, and the return type. It does not exhaustively explain each pass, but the structured report schema likely provides those details, making the description sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'workflow', is described in the schema as a generic object with 0% coverage. The description adds that it can be a ComfyUI editor-format (top-level nodes/links arrays) or presumably a native workflow, and that the pre-pass will detect this. However, it does not detail the expected structure of a native workflow or the ValidationReport fields (though output schema exists).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Validate a workflow with a 6-pass check' and returns a structured ValidationReport, which specifies the action and output. The mention of a pre-pass for ComfyUI editor-format distinguishes it from validation-related siblings like comfy_validate_before_queue.
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 context for when this tool is used by enumerating the six validation passes and the special pre-pass for editor-format workflows, implying comprehensive validation. However, it does not explicitly name alternative tools or explain when NOT to use it, though the pre-pass serves as a form of exclusion for editor-format inputs by instructing re-export.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral value by specifying the return type ('structured VRAMStatus') and the per-device granularity, which is not inferable from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core action ('Check current GPU VRAM usage') and then provides the key output detail. Every word earns its place; 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 the tool's simplicity (no parameters, existing output schema), the description is complete. It states what the tool does and what it returns, which is all an agent needs to select and invoke it correctly. The structured output schema will provide further return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter behavior to explain. The description appropriately omits parameter information. Baseline 4 for no parameters applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Check') and resource ('GPU VRAM usage'), and distinguishes it from siblings like comfy_get_gpu_info by specifying the structured output (VRAMStatus). The one-sentence description leaves no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: any time current GPU VRAM usage is needed. It does not explicitly mention alternatives or exclusions, but the purpose is specific enough to be unambiguous. Without a direct comparison to sibling tools, it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds that it's a 'one-shot snapshot' (no streaming or long-running) and clarifies the returned structure, which is useful context beyond the annotations. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the essential purpose ('One-shot snapshot') and followed by the return structure. No filler words, 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?
With 0 parameters, a rich output schema, and comprehensive annotations, the description covers the necessary selection and invocation context. It explains what is returned (queue counts, event types, active job summary), making it complete for a read-only snapshot 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?
The tool has zero parameters, so the baseline is 4. The description provides no parameter information, but none is needed. It does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'One-shot snapshot of system dynamics' with explicit components (queue, recent events, active jobs). It specifies the return type and differentiates from siblings like comfy_get_queue or comfy_get_events by combining multiple aspects into a single snapshot.
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 'one-shot snapshot' phrasing implies use when a quick overview of system dynamics is needed rather than querying individual sub-systems. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide a strong safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds useful behavior beyond that: it reveals that `inputs` are per-node overrides 'applied to the blueprint's nodes when inserted,' and that the result is a workflow dict. No contradiction with annotations 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 short and front-loaded: one clear action sentence followed by two compact argument notes. Every sentence earns its place, with 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 two simple parameters, strong annotations, and an existing output schema, the description covers the remaining uncertain pieces: where `name` comes from, how `inputs` interact with nodes, and what is returned. Nothing critically missing for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It does: `name` is a blueprint name from `comfy_list_blueprints`, and `inputs` is an optional `{node_id: {input_name: value}}` override map. It lacks examples or defaults, but these are present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening statement 'Materialize a blueprint into a workflow dict' gives a specific verb and resource, and immediately distinguishes it from `comfy_list_blueprints` and other workflow composition tools. It even points to the source of the `name` argument ('from comfy_list_blueprints'), which removes ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes where the tool fits: take a blueprint name produced by `comfy_list_blueprints` and produce a workflow dict. It gives enough context for correct use, but it does not explicitly call out when not to use it or name alternatives such as `comfy_apply_template`, so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value with the explicit guarantee 'It never starts, stops, or changes the instance' and outlines the inspection method (API argv, PID/process tree, registry), going beyond the annotation fields without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly scoped sentences: the first states the intent and outputs, the second adds context, method, and safety guarantee. Every sentence earns its place with no filler or repetition of the title or schema.
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 zero parameters and an output schema present, the description covers purpose, method, scope, and non-mutation guarantee. It is complete enough for an agent to select and invoke this tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. The description correctly implies a no-input diagnostic action, and the baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Discover' and enumerates concrete outputs: connected instance, supervisor, paths, ports, and versions. It clearly distinguishes this diagnostic tool from status/stats tools by emphasizing connection topology and local Desktop process correlation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: 'For a local Comfy Desktop endpoint' and explains what inputs it correlates. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough for an agent to understand when this diagnostic 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 declare readOnlyHint=true and idempotentHint=true, and the description aligns with this by not indicating any side effects. The description adds value beyond annotations by explaining the specific verdict logic and the additional output of the install flag. It does not contradict annotations, but it doesn't detail how the inspection is performed or whether it accesses system APIs, which is minor given the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear overview, a list of verdicts with thresholds, and a note on the additional output. It is front-loaded with the primary purpose and each sentence contributes to understanding the tool. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters and an output schema is present, the description is complete for the tool's complexity. It fully explains the verdicts and the install flag, so the agent can confidently use the result to route workloads. No gaps in critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline is 4. The description explains the output semantics extensively, including the three verdicts and the install flag, which goes beyond what an empty schema provides. This is useful for understanding the tool's return value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: inspect connected GPU and recommend local vs Comfy Cloud routing. It distinguishes itself from siblings like comfy_check_vram and comfy_get_gpu_info by focusing on the routing decision. The three verdicts provide specific, actionable output.
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 explains when to use this tool: before deciding to run workloads locally or on cloud. It also gives concrete thresholds for each verdict, making it clear how to interpret the result. However, it does not explicitly state when NOT to use it versus alternatives like comfy_check_vram, but the purpose differentiation is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond the annotations: it clarifies that the query is case-insensitive, the default folder scope, and the effect of `include_non_model_files`. These details complement the readOnly and idempotent hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—three sentences—and directly addresses the tool's behavior and parameters. No unnecessary wording or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives enough context for a user to understand what the tool does, its default and optional behaviors, and the meaning of each parameter. It does not describe the return format, but that is not critical for a search tool and may be covered by an output schema not shown here.
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?
Each parameter is thoroughly explained: `query` is a case-insensitive substring match, `folders` restricts the search, and `include_non_model_files` includes specific file types. This fully covers the schema's properties with meaningful descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for models by name across folders.' It specifies the resource (models) and the action (search), distinguishing it from sibling search tools for nodes, techniques, and history.
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 explains default behavior (searches all folders) and provides an explicit example of narrowing with `folders`. It also clarifies the `include_non_model_files` parameter. However, it does not explicitly mention when not to use this tool versus other search tools, though the context is fairly 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 explicitly states it is destructive and cannot be undone, complementing the destructiveHint annotation. It also explains the confirm parameter's behavior (false triggers elicitation, true skips prompt), providing operational transparency beyond the structured 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 succinct, comprising two clear sections: purpose and parameter explanation. Every sentence adds value, with no filler or redundancy, making it highly concise and well-structured.
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 destructive action with one parameter and no required fields, the description covers the action, its irreversible consequence, and the parameter's role. It is complete for an agent to safely invoke the tool, even without detailing the output schema.
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 schema description coverage at 0%, the description fully compensates by detailing the confirm parameter: false means explicit confirmation via elicitation, true skips the prompt. This adds meaningful semantics beyond the schema's default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clears ALL execution history, explicitly distinguishing it from partial deletion or queue clearing by emphasizing 'ALL' and destructive nature. This differentiates it from siblings like comfy_delete_history and comfy_clear_queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention alternatives or provide when-to-use guidance relative to other history tools. While the 'ALL' scope implies a full reset scenario, it does not contrast with comfy_delete_history or comfy_clear_queue, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safe, read-only, idempotent behavior with no destructive side effects. The description adds behavioral context about what fields are extracted (status, errors, per-node traceback, completed nodes) and references the underlying /history endpoint, giving extra clarity beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and well-organized: a one-sentence purpose, a two-sentence technical explanation of source and extraction, and an Args section. No redundant filler; each sentence adds value and the key information appears early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param), the presence of an output schema, and thorough annotations, the description covers all necessary aspects: purpose, input source, behavior, and the fact that it simplifies raw JSON. No missing information that would hinder correct invocation.
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?
The schema provides only a bare prompt_id string with no description, and schema coverage is 0%. The description compensates fully by specifying that the prompt_id is the one returned by comfy_queue_prompt, giving precise origin and usage guidance for the single 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?
The description clearly states the tool retrieves execution logs and error tracebacks for a specific prompt. It explicitly distinguishes itself by extracting only log-relevant fields from the full ComfyUI history response, separating it from broader history/result tools like comfy_get_history or comfy_get_run_result.
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 solid context: it tells users to pass a prompt_id from comfy_queue_prompt and explains the tool filters down a verbose response to useful log data. While it does not explicitly name alternative tools or say when not to use it, the purpose and input source make the usage clear enough.
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 mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that: user blueprints shadow bundled ones on name collision, and native entries are tagged with source: 'native'. This helps an agent anticipate result composition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence states the purpose, followed by a compact source list and two relevant behavioral notes. Every sentence adds information not already present in the schema or annotations.
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 simple one-parameter interface and rich annotations, the description is complete: it covers all source options, the default value, name-collision behavior, and native tagging. Since an output schema exists, the absence of return-format details is not a gap.
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?
The schema only defines a single source parameter with no enum values and 0% description coverage. The tool description fully compensates by defining each valid value ('all', 'user', 'bundled', 'native'), their meanings, and the default behavior, plus the COMFY_BLUEPRINT_DIR association.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List subgraph blueprints from the configured sources.' It is specific about the object (subgraph blueprints) and the source-filtering behavior, which distinguishes it from sibling listing tools like comfy_list_models or comfy_list_extensions.
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 a clear usage context by enumerating the four source options and the default 'all' behavior. It does not explicitly name alternatives or exclusions, but the source-filtering semantics make it evident when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's job is to add context. It does so by specifying pagination behavior (limit/offset), the optional include_non_model_files flag and what it includes, and the fact that the folders are those exposed by the connected ComfyUI instance. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly efficient: a one-sentence purpose statement followed by a bulleted list of parameters. It front-loads the core purpose ('List models in a folder with pagination') and each sentence earns its place with no redundant fluff.
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 an output schema exists, the description wisely avoids describing return details and focuses on usage, prerequisites, and parameter semantics. It fully covers the listing behavior, pagination, and the optional non-model file inclusion, making it complete for this tool's complexity.
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 carry the full burden for parameter documentation. It does this excellently: folder is explained with concrete examples and a cross-reference to comfy_list_model_folders, limit/offset are defined as pagination controls, and include_non_model_files is detailed with specific file types. This is a perfect 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 clearly states 'List models in a folder with pagination' and mentions the structured return type (ModelList). This specific verb+resource combination distinguishes it from siblings like comfy_search_models (search across folders) or comfy_list_model_folders (list folders), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite by instructing users to call comfy_list_model_folders to see valid folders, which is a valuable pointer. However, it stops short of explicitly stating when not to use this tool versus alternatives like comfy_search_models or comfy_refresh_models, so it does not fully meet the 'explicit when/when-not' criterion.
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 signal idempotent and non-destructive behavior, and the description adds meaningful details: writes are atomic and a sidecar manifest is created. It does not elaborate on manifest naming or overwrite behavior, but with annotations covering safety, this is adequate and contains no 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 front-loaded with a one-sentence purpose followed by a compact Args list. Every line earns its place and there is no filler or repetition of schema details beyond useful parameter semantics.
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 a simple tool with an output schema available, the description covers all parameters, the core behavior, and key traits like atomicity and the sidecar manifest. It is complete enough for an agent to select and invoke the tool 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?
The input schema has 0% description coverage, but the Args section fully compensates by documenting all four parameters. It adds semantics such as filename being the image filename in ComfyUI outputs, subfolder as optional subfolder, output_dir defaulting to COMFY_OUTPUT_DIR, and prompt_id enriching the manifest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Download an image from ComfyUI and save to local disk atomically with a sidecar manifest.' This clearly states what the tool does and distinguishes it from siblings like comfy_send_to_td and comfy_send_to_blender by naming local disk as the destination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when an image needs to be transferred from ComfyUI outputs to a local directory. It does not explicitly mention alternatives or exclusion criteria, but the context is unambiguous and sufficient for selection among the many ComfyUI tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context: the return value is Mermaid source rather than a rendered image, it uses flowchart TD style, and the title becomes a comment in the diagram. 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 compact and front-loaded: it states the core purpose, the output type and how to use it, then the argument semantics. Every sentence adds value, and the Args section is minimal but informative.
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, idempotent utility with two parameters and a simple string-returning behavior, the description is complete. It explains the input format, output format, and practical usage (paste into a renderer). The annotations and output schema cover the remaining trust and return-value context.
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 fully explain parameters. It does: workflow is defined as an API-format {node_id: {class_type, inputs}} dict, and title is explained as an optional string inserted as a diagram comment. This gives the agent enough semantic detail to construct both arguments correctly.
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 verb and resource: 'Render an API-format workflow as a Mermaid flowchart.' It clearly states what the tool produces and is easily distinguishable from sibling tools like validate_workflow, export_workflow, and inspect_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool—when you need a Mermaid rendering of an API-format workflow—and explicitly frames the output as renderable Mermaid source. It doesn't mention explicit exclusions or alternatives, but the unique visualization purpose 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 beyond the annotations (readOnlyHint=true, idempotentHint=true) by detailing the default behavior (no bytes transfer), the effect of include_size (requires downloading each image), and even discloses a historical bug in the pre-1.5.3 implementation that downloaded full bodies. This is rich behavioral context that helps the agent predict costs and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a summary line, a detailed paragraph, and a bulleted Args section. It includes a historical note that adds transparency but is slightly auxiliary. Overall, it's efficient and front-loaded, with each sentence contributing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return values are already specified. The description covers the tool's purpose, behavior, parameter details, and usage cautions. For a batch metadata lookup with an optional download path, it is fully complete without requiring references to sibling tools.
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 fully carries the burden. It provides an 'Args' section explaining each parameter: filenames as a list, subfolder as optional, and include_size with its default and the implication of downloading. It adds caveats about include_size usage, giving meaningful semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Get lightweight metadata for multiple output images.' It explicitly mentions 'multiple' and 'metadata', distinguishing it from single-image retrieval tools like comfy_get_output_image or comfy_list_output_images. The purpose is concise and 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 explains the default metadata-only behavior and cautions that include_size=True downloads each image and 'should only be used for short lists.' While it doesn't explicitly name alternative tools for downloading actual image bytes, the 'no image bytes cross the wire' wording implies that for full downloads, other tools (e.g., comfy_get_output_image) would be appropriate. It provides clear usage context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description goes beyond these by explaining that launch blocks when a healthy endpoint is connected unless allow_parallel=True, and that background=True runs as a detached daemon while background=False blocks until exit. It also mentions mutation requires confirm. This adds valuable context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into a clear opening paragraph and a bullet-like Args list with concise per-parameter explanations. The opening paragraph is information-dense and front-loaded with the most critical constraint (no implicit 8188 fallback). It is slightly long but every sentence adds value; the Args list is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, mutation, process launch), the description is complete. It covers launch blocking semantics, parallel execution, workspace selection, and argument forwarding. The output schema exists, so return values need not be detailed. The description fully compensates for low schema coverage and provides comprehensive guidance for a process-spawning 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 fully explain parameters, and it does. Every parameter (background, port, host, workspace, extra_args, allow_parallel, confirm) is described with concrete semantic meaning and even examples for extra_args (e.g., ['--listen', '0.0.0.0', '--cpu']). This far exceeds the baseline of 3 given zero coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear, specific verb 'Start' and resource 'ComfyUI workspace via comfy-cli'. It explicitly states the primary function and distinguishes it from siblings like comfy_stop_server (which stops) and comfy_restart (which restarts). The mention of 'explicitly selected' and 'no implicit 8188 fallback' further clarifies scope.
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 explicit when-to-use guidance, including the requirement for explicit workspace and port, and the condition for allow_parallel. It also implicitly differentiates from other lifecycle tools by naming the prevention of accidental parallel processes. However, it does not name alternative tools directly, but the lack of an implicit fallback and the parallel launch behavior give clear usage 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 give basic safety hints (readOnlyHint=false, destructiveHint=false), but the description adds critical context: it deep-copies the workflow so the caller's dict is unchanged, uses cryptographic randomness via secrets.randbelow, and avoids shared random streams for concurrency. This goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence. Subsequent sentences provide useful behavioral details, but the explanation is slightly longer than strictly necessary (e.g., the cryptographic randomness detail, while relevant, could be trimmed). The Args/Returns structure aids navigation.
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 tool's complexity: it covers the input format, the transformation semantics, the default versus force behavior, the deep-copy guarantee, and the return shape. Since an output schema exists, the Returns section succinctly summarizes the structure of the result.
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?
The schema has 0% property description coverage, but the description's Args section thoroughly defines both parameters: 'workflow' as an API-format dict that is deep-copied, and 'force' as an override for randomizing every seed widget. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb-resource pair: 'Replace seed sentinels (-1) with fresh random uint32 values.' This precisely distinguishes the tool from its many siblings, which handle workflows, models, or system stats, none of which target seed randomization.
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 explains the default behavior (only -1 widgets randomized), the opt-in pattern, and the 'force=True' alternative. This gives clear context for when to use each mode, though it does not explicitly mention alternative tools or states when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses that it re-reads the current cache and explicitly states it does NOT trigger a server-side rescan, which is critical behavioral nuance. It also clarifies the return format (per-folder counts), adding transparency not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a single clear sentence for purpose followed by a concise note on behavior and return value. Every sentence contributes meaningful information without fluff, and it is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, the description is complete: it states what it does, what it does not do (filesystem rescan), and what it returns (per-folder counts). The presence of an output schema and annotations further supplements the context, so nothing essential 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?
With zero parameters, the description does not need to explain any. According to the rubric, a 0-parameter tool receives a baseline of 4. The description adds no unnecessary parameter info, so it maintains this baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Re-fetch the model list from ComfyUI across every known folder.' It clearly identifies the resource (model list) and scope (every known folder), distinguishing it from listing tools like comfy_list_models by emphasizing it's a refresh operation. The mention of returning per-folder counts adds further specificity.
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 note explains that it re-reads the cache and does NOT trigger a filesystem rescan, which informs when to use it (to refresh cached data) and when not to (if a rescan is needed). However, it does not explicitly reference alternative tools like comfy_list_models for listing, leaving some ambiguity about when to choose this over 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 adds behavioral context beyond annotations: it explains the confirmation flow (If False, asks via elicitation; True skips prompt) which is not in annotations. It also reiterates the destructive nature, reinforcing the destructiveHint. This is valuable and does not contradict 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 extremely concise: a single sentence stating the action and a brief Args section. It is front-loaded with the main purpose and the parameter explanation is minimal yet complete. Every word earns its place, with no fluff or redundancy beyond the useful 'Destructive.' warning.
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 has only one optional parameter and an output schema exists, the description fully covers the core functionality and the parameter behavior. It defines exactly what is cleared (pending prompts) and the confirmation protocol. No additional context is necessary 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name and type with no description (coverage 0%), but the description fully explains the 'confirm' parameter: its default (false), its effect (asks for confirmation vs skips), and the elicitation mechanism. This compensates completely for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: clearing all pending prompts from the queue. It uses a specific verb ('Clear') and resource ('all pending prompts from the queue'), and distinguishes it from siblings like comfy_get_queue (retrieval) and comfy_interrupt (interrupting current runs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to clear the queue) but does not explicitly reference alternative tools or when not to use it. Given the many sibling tools for queue management, adding exclusionary guidance would improve it, but the core usage 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?
Beyond annotations (which already indicate mutation, idempotency, and non-destructiveness), the description discloses the temp-file serialization, automatic cleanup, and default 600s timeout. It accurately reflects the operation without contradicting any 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 text is compact, front-loaded with the main action, and uses a clear 'Args:' section. Every sentence adds value—no filler or repetition.
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 two parameters, one nested object, and an output schema (which covers return values), the description fully describes behavior, including the long-running nature and timeout. It is complete for its complexity.
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?
The description adds critical meaning: workflow must be in API format, and workspace is an optional path passed to comfy-cli. This goes beyond the bare schema (which only says 'object' and 'string') and compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Auto-install every custom-node package the workflow references.' It clearly distinguishes from siblings like comfy_install_node by focusing on workflow-level dependencies. The wrapper command is named, adding precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for installing all dependencies referenced by a workflow, and notes it is long-running with a timeout. It does not explicitly list alternative tools or when not to use it, but the purpose is clear enough that an agent would know when this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description discloses exact return shapes for success, failure, and missing binary scenarios. It also explains line_count==0 semantics and the API preference logic, giving comprehensive behavioral expectations.
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 with clear sections for overview, args, and returns. Every sentence contributes value—no fluff or redundancy—and the formatting makes it easy to parse.
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 all relevant scenarios: success with different line counts, failure with return codes, and error with install hints. It also explains parameter behavior and edge cases, making it complete enough for an agent to invoke correctly without further clarification.
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?
Each parameter is explained in the Args section with defaults and behavior, fully compensating for the 0% schema description coverage. The explanation of prefer_manager_api as trying /v2/customnode/installed first is particularly actionable.
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 'List custom-node packages' with a specific verb and resource, distinguishing it from siblings like comfy_list_extensions and comfy_list_node_types. The additional mention of preferring the live Manager V2 API adds method-level specificity.
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 explains when to use Manager V2 vs comfy-cli fallback, and when each is appropriate. It doesn't explicitly name alternative tools among the siblings, but the scope is unambiguous and the fallback guidance is helpful for context selection.
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 important behavioral details beyond annotations: the caller's workflow dict is deep-copied and not mutated, images are uploaded to ComfyUI's input directory, labels patch matching widgets, and the response includes an auto_snapshot field. This adds substantial non-obvious context and is consistent with 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 front-loaded with a one-sentence purpose, then transitions into a tight Args/Returns structure. Every sentence contributes operational or semantic value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with nested objects, zero schema-level parameter descriptions, and meaningful side effects, the description is remarkably complete. It covers purpose, parameter behavior, mutation safety, queueing semantics, and a custom return field. The presence of an output schema makes the explicit return explanation acceptable and useful.
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 carries the full parameter-documentation burden. It compensates well: it explains workflow as an API-format dict with copy semantics, inputs as label-to-local-path mappings with explicit targeting and wildcard patching, and front with queue-position behavior. All three parameters gain meaningful semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action chain—"Upload local images, inject as workflow inputs, then queue"—and explicitly frames the tool as combining the three-step img2img/inpaint flow into one call. This clearly distinguishes it from sibling tools like comfy_queue_prompt, comfy_upload_image, and comfy_set_widget_value.
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 signals when this tool is useful: when a caller wants to perform the upload + patch + queue workflow for local images in one step, especially for img2img/inpaint. It does not explicitly name alternative tools or state when not to use it, so it misses the full exclusion guidance needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructive, idempotent), the description discloses that it invokes comfy-cli, requires explicit confirmation or MCP elicitation, only targets explicitly selected non-Desktop servers, and details three distinct return shapes including the failure case when comfy-cli is not on PATH. The idempotent behavior is consistent with the 'failed' status when no server is running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a precise one-sentence purpose, then a focused paragraph on exclusions/alternatives, followed by clearly labeled Args and Returns sections. Every sentence adds value, with no redundant fluff.
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 destructive, optional-parameter tool, the description covers prerequisites (comfy-cli on PATH), selection logic, confirmation flow, return shapes, and common failure modes. The output schema exists, but the description still succinctly explains the three JSON shapes, making the tool fully understandable without external docs.
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 has 0% description coverage, but the description compensates fully by explaining each parameter's purpose: workspace selects the install path, expected_instance_id comes from comfy_instance_doctor, expected_pid is a listener PID selector, and confirm gates the destructive action. This adds real meaning beyond raw schema names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Stop an explicitly selected non-Desktop ComfyUI server via comfy-cli.' It clearly distinguishes this tool from sibling tools like comfy_restart and comfy_launch_server, and clarifies it does not handle Desktop-supervised instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to use: 'Desktop-supervised instances are never handed to comfy stop' and gives alternatives: 'Use Comfy Desktop itself for a full stop, or comfy_restart for Manager V2 restart.' This is strong when/when-not guidance.
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:

[![ComfyPilot MCP server](https://glama.ai/mcp/servers/dreamrec/ComfyPilot/badges/card.svg)](https://glama.ai/mcp/servers/dreamrec/ComfyPilot)

Score Badge

Copy to your README.md:

[![ComfyPilot MCP server](https://glama.ai/mcp/servers/dreamrec/ComfyPilot/badges/score.svg)](https://glama.ai/mcp/servers/dreamrec/ComfyPilot)

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/dreamrec/ComfyPilot'

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