Skip to main content
Glama

upload_image

Uploads local images, videos, or audio into ComfyUI's input directory, stages existing outputs as inputs for multi-stage workflows, and sends generated files to cloud storage.

Instructions

Put a file where ComfyUI (or cloud storage) can read it. Driven by the action parameter:

  • action:"image" — Upload a local image file to the connected ComfyUI's input/ directory via the HTTP /upload/image endpoint so it can be referenced in LoadImage nodes. Works for both local and remote ComfyUI. Returns the stored filename.

  • action:"video" — Upload a local video file (.mp4, .mov, .webm, .avi, .mkv, .m4v) to the connected ComfyUI's input/ directory via the HTTP /upload/image endpoint for use in video-loading nodes such as VHS_LoadVideo (ComfyUI-VideoHelperSuite). Works for both local and remote ComfyUI. Returns the stored filename.

  • action:"audio" — Upload a local audio file (.wav, .mp3, .flac, .ogg, .m4a, .aac) to the connected ComfyUI's input/ directory via the HTTP /upload/image endpoint for use in audio-conditioned workflows (e.g. LoadAudio). Works for both local and remote ComfyUI. Returns the stored filename.

  • action:"stage" — Stage an EXISTING ComfyUI output (or temp/preview) as an INPUT so the next stage's loader (LoadImage / VHS_LoadVideo / LoadAudio) can read it. This is the CORRECT way to chain a multi-stage pipeline (e.g. Krea2 image → LTX video → WAN extend): it fetches the output's bytes from the server via /view and re-registers them as an input via /upload/image — the same endpoints get_image and the uploads above use. Because it goes entirely through the server API, it works even when ComfyUI was launched with a CUSTOM input/output directory. Do NOT instead copy the output file or guess a filesystem input/ path — the server's input dir may be custom and it will reject the file ("Invalid image file"), wasting the render. Pass an existing output reference ({ filename, subfolder?, type? }); the media kind (image/video/audio) is inferred from the extension unless you set kind. Returns the registered input { filename, subfolder, type: "input", kind } — drop the returned filename straight into the loader's image/video/audio widget.

  • action:"output" — Upload a generated ComfyUI output to CLOUD storage (this is the only action that sends bytes off the machine). Source can be asset_id or a local path under COMFYUI_PATH/output. Destination can be S3, Azure Blob, HTTP PUT, or HuggingFace via the hf CLI.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoaction:"stage" — force the media kind instead of inferring it from the file extension.
pathNoaction:"output" — path to a generated output under COMFYUI_PATH/output. Provide exactly one of asset_id or path.
typeNoaction:"stage" — source directory the asset lives in: output (default) or temp (previews).
actionYesWhat to upload and where. "image"/"video"/"audio" send a LOCAL file (`source_path`) to ComfyUI's input/ directory; "stage" re-registers an EXISTING server-side output (`filename`) as an input; "output" ships a generated output to cloud storage (`destination`).
asset_idNoaction:"output" — registered asset id from a completed job. Provide exactly one of asset_id or path.
filenameNoTwo meanings, one per action. actions "image"/"video"/"audio" — OPTIONAL override for the filename in ComfyUI's input/ directory (auto-detected from source_path if omitted). A path prefix (e.g. assets/clip.mp4) places the upload in that SUBFOLDER of input/ — ".." is refused — and the returned filename reference includes the subfolder, since loaders need the qualified path. action:"stage" — REQUIRED filename of the EXISTING output/temp asset to re-register (from get_history or get_image action:"list_outputs"), e.g. LTX_video_00001.mp4; its destination name override is `as_filename`, not this field.
subfolderNoaction:"stage" — subfolder the source asset currently lives in, if any.
as_filenameNoaction:"stage" — override the filename it is registered under in the input/ directory (defaults to the source filename).
destinationNoaction:"output" — REQUIRED. Exactly one upload destination.
source_pathNoAbsolute path to the local file to upload. REQUIRED for actions "image", "video" and "audio".
Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers: it discloses the HTTP endpoints used, behavior for local and remote ComfyUI, handling of custom input/output directories, return values, and the important fact that only the 'output' action sends bytes off the machine. It also surfaces edge-case behavior like '..' being refused in filename paths.

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 front-loaded summary and action-based bullets, which is appropriate for a complex tool with five modes. However, phrases like 'Works for both local and remote ComfyUI' and 'via the HTTP /upload/image endpoint' are repeated three times each, adding unnecessary 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 the tool's high complexity (10 parameters, nested destination objects, multiple action modes) and no output schema, the description is remarkably complete. It covers all actions, parameter interactions, return values, edge cases, and even notes an API compatibility quirk ('async' accepted but uploads complete before returning).

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?

Although schema coverage is 100%, the description adds substantial parameter semantics beyond the schema: it explains the dual meaning of 'filename' across actions, subfolder qualification for loaders, the 'as_filename' override for staging, and the exact relationship between 'action', 'source_path', 'asset_id', and 'destination'. The examples and warnings make parameter behavior significantly clearer.

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 as an upload utility for ComfyUI and cloud storage, using a specific verb ('Put a file') and a concrete resource. It differentiates the five action modes (image/video/audio/stage/output) with enough specificity to distinguish them from each other and from sibling tools like get_image.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance for each action, including the 'stage' action as the correct way to chain multi-stage pipelines. It also gives a clear exclusion: 'Do NOT instead copy the output file or guess a filesystem input/ path' because custom input directories will reject the file. This is exemplary usage guidance.

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

Install Server

Other Tools

Latest Blog Posts

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/artokun/comfyui-mcp'

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