Skip to main content
Glama
ousiqwq

comfy-mcp-local

by ousiqwq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fetch_template

Retrieve a template's workflow JSON to a local path and verify if it can run on your ComfyUI install, enabling immediate execution or identifying missing components.

Instructions

Write a template's runnable workflow JSON to out_path; report if it can run here.

Wraps comfy templates fetch <name> --out <path>. Returns {"path": ..., "local_check": {...}} — completing the on-ramp::

result = fetch_template("flux_dev", out_path)
if result["local_check"].get("runnable"):
    run_workflow(result["path"])
else:
    ...  # relay what's missing, or validate_workflow(result["path"]) first

Step 4 is not optional — gallery content is never compared to this install until then.

Args: out_path: only the user can write here — a shared path risks TOCTOU between the check and the run. check_local: True (default) makes local_check BE step 4. {"checked": false} means the comparison could not be made — it leaves step 4 UNDONE; run validate_workflow first. False moves the gate onto you, it does not remove it. Read with .get("runnable"); a checked: false block has no such key.

Gotchas: - A bare validate_workflow is WEAKER than local_check: an old UI-export file checks ZERO nodes, reporting valid: true (blind spot 3) — watch non_node_key warnings with no converted_from_ui. - Freshness: CACHED, 24h TTL as of v1.14.0 (this server's floor); refresh with comfy templates refresh. NOT read from the local install.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
out_pathYes
check_localNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses caching (24h TTL, refresh command), that it is not read from local install, the TOCTOU risk with shared out_path, the semantics of check_local and how to read the returned local_check block, and the difference between checked and unchecked states. This is thorough and beyond what the schema alone provides.

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 long but structured with a summary, an example, Args, and Gotchas sections. Every sentence adds value—no redundancy. It is front-loaded with the core purpose and then elaborates. It is slightly dense but appropriate for the tool's complexity.

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 3 parameters, no output schema, and no annotations, the description is remarkably complete: it explains the return structure, the local check behavior, caching, freshness, and alternatives. An agent has everything needed to call it correctly and interpret the result. No obvious 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 description coverage is 0%, so the description must compensate. It explains out_path (user-write-only, shared-path TOCTOU risk) and check_local (default true, meaning, and how to interpret the result). The name parameter is not described but is self-evident from the wrapped command; the two parameters with meaningful nuance are fully covered.

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 pair: 'Write a template's runnable workflow JSON to out_path; report if it can run here.' It then names the wrapped command (comfy templates fetch) and explains the return value, distinguishing its role in the on-ramp from siblings like get_template, search_templates, and validate_workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage context: it completes the on-ramp, includes a code snippet showing when to call run_workflow versus validate_workflow, and warns that a bare validate_workflow is weaker than local_check. It also states that step 4 is not optional, effectively telling the agent when this tool is required and when to defer to validate_workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools