Skip to main content
Glama
ousiqwq

comfy-mcp-local

by ousiqwq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

download_model

Fetch a model file by URL directly into your local ComfyUI models directory. Submit the download in the background or wait for completion, with support for custom filenames and timeouts.

Instructions

Download a model file into the LOCAL ComfyUI models dir, by URL.

Wraps comfy model download --url <url> [--relative-path <path>] [--filename <name>] --background (the singular model verb, not the models catalog search_models reads). Fetches a known URL, no hub search. The transfer is SUBMITTED, not held open: comfy-cli detaches a worker and returns a download_id, the handle for download(action="status"/"wait"/"cancel").

Args: relative_path: workspace-relative; first segment must be models (e.g. models/loras); a bare folder name like loras is rejected. wait: if True (default), poll until done or timeout_seconds elapses. timeout_seconds: end-to-end budget for the waited call, submit included; default 110s sits under a typical client's ~120s budget.

Returns: wait=True: the final status, or {"timed_out": True, "download_id": ..., "status": ...} on expiry — not an error, keep polling that id. wait=False: the submit payload (download_id, dest, total_bytes, status).

Gotchas: - comfy-cli writes straight to the FINAL path while transferring, so a present file proves nothing. download(action="status") reporting completed is the only proof the model is usable. - REFUSES when a remote ComfyUI is configured (COMFYUI_URL/ COMFYUI_HOST): this always writes LOCALLY, so a remote target would silently get the wrong disk. Set COMFY_MCP_REMOTE_SHARED_MODELS=1 if that disk is actually shared.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
waitNo
filenameNo
relative_pathNo
timeout_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A5/5.0
Behavior5/5

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

No annotations are present, but the description fully carries the behavioral burden: it explains the transfer is submitted asynchronously, writes directly to the final path, returns a download_id, times out without error, and refuses remote targets. This goes well beyond basic expectations and prevents misuse.

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 long but tightly organized with Args, Returns, and Gotchas sections. Every sentence adds operational value, and the most critical distinctions and failure modes are front-loaded.

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 asynchronous tool with no annotations and no output schema, the description is fully complete: it covers parameters, return shapes for both wait modes, timeout semantics, remote-target refusal, and evidence-of-completion gotchas. An agent has everything needed to invoke and interpret the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does. It explains relative_path's workspace-relative 'models' requirement, wait's polling behavior, timeout_seconds' end-to-end budget and default rationale, and references url/filename in the wrapped command.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: downloading a model file into the local ComfyUI models directory by URL. It also distinguishes itself from the catalog search tool by explicitly naming 'search_models' as the sibling it is not, so an agent can select it correctly.

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?

Clearly says this is for known URLs and not hub search, and names the alternative 'search_models'. It also gives concrete routing cues such as the singular 'model' verb, the refusal behavior with remote ComfyUI, and the environment variable override, leaving little to inference.

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