Skip to main content
Glama

get_image

Fetch, browse, and inspect ComfyUI images and registered assets: retrieve by filename or asset ID, list recent outputs, convert image formats, and analyze color.

Instructions

Fetch, browse and inspect ComfyUI images and registered assets. Driven by the action parameter:

  • action:"get" — Fetch a generated image from ComfyUI by FILENAME and return it as an inline image. Video/audio outputs (e.g. a VHS_VideoCombine .mp4) are saved to save_dir with their original extension instead of being rendered inline. Works with remote ComfyUI instances — does not require COMFYUI_PATH. Use get_history (action:"list") first to obtain the filename.

  • action:"view" — Fetch a registered asset's bytes by ASSET ID and return them as an inline image so the agent can see the result. Use this after a render completes (asset_id is included in the completion notification) to inspect, critique, or compare generated images. Only supports image mime types (PNG/JPEG/WebP); audio/video assets must be saved to disk via action:"get".

  • action:"list_outputs" — List recently generated image AND video files from ComfyUI's output/ directory, newest-first, with each file's kind ('image' | 'video'), subfolder, size, and modification time. Covers stills (.png/.jpg/.jpeg/.bmp) and video/animation outputs (.mp4/.webm/.mov/.mkv/.m4v/.avi/.gif/.webp). LOCAL ComfyUI (COMFYUI_PATH set): a RECURSIVE filesystem scan of output/ — includes subfolders like video/ that VHS/SaveVideo write to, and reports size + modification time. REMOTE ComfyUI: derives the list from /history over HTTP instead (size/modified are unavailable and omitted). It does NOT return the media bytes themselves — fetch those with action:"get". USE THIS TO CONFIRM A VIDEO RENDER (e.g. VHS_VideoCombine / LTX / WAN output) when get_history (action:"list") shows the prompt done but lists no output: VHS-style video nodes write the file but often do NOT register in ComfyUI's /history, so the local filesystem scan is the reliable way to verify the .mp4 exists — then chain it with upload_image (action:"stage"). THAT GUARANTEE IS LOCAL-ONLY AND INVERTS ON A REMOTE TARGET: with no disk to scan, this falls back to the very /history that omits those videos, so a REMOTE listing can neither confirm nor deny a VHS video render, and absence from it is NOT evidence the file is missing. Check a specific filename with action:"get" or upload_image (action:"stage") instead — both read /view, straight from the output directory. Every remote result says so in its own text. Read-only.

  • action:"convert" — Re-encode a generated image to PNG, JPEG, or WebP and return it inline as an image content block. Source can be a registered asset_id or a path under the local ComfyUI output directory. Optionally writes the converted image back under the output directory and reports source/output size plus bytes saved.

  • action:"analyze_color" — Measure the color of a rendered image (not by eye): returns black/white points, contrast (luma std), saturation, per-channel means + cast, and clipping — plus heuristic flags (washedOut, lowContrast, liftedBlacks, dimHighlights, lowSaturation, colorCast) and a one-line verdict. Source = asset_id, a ComfyUI output ref (filename/subfolder/type), or an image path. Pass reference_path to shot-match against a known-good frame (target−reference deltas). Set histogram:true to also get an overlaid R/G/B/luma histogram PNG. Use this to diagnose 'washed out' objectively and decide a color fix; for a video, extract a frame to PNG first.

  • action:"list_assets" — List recently generated assets, newest-first. Each call first reconciles ComfyUI's /history, so outputs are listed even when this session did not watch the render complete (e.g. queued via panel_run, by an earlier session, or before a server restart) — those are tagged source:'history-reconcile', versus source:'watched' for renders this server saw finish. Returns count + assets (asset_id, prompt_id, filename, url, source, created_at). The registry is ephemeral and clears on server restart; records expire after COMFYUI_ASSET_TTL_HOURS (default 24h), and only the most recent completed runs are reconciled — use get_history (action:"list") / action:"get" by filename for anything older.

  • action:"asset_metadata" — Get full provenance for a registered asset including the workflow snapshot that produced it. Use this to inspect the parameters that generated an image before calling generate_image (action:"regenerate") with overrides.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoA source image path. action:"convert" — a path under COMFYUI_PATH/output (provide exactly one of asset_id or path). action:"analyze_color" — an absolute image path, or a path under the ComfyUI output dir (videos: extract a frame to PNG first).
typeNoComfyUI directory the file lives in: output (default), input, or temp. Used by action:"get" and by action:"analyze_color" when the source is a `filename`.
limitNoaction:"list_outputs" — max media files to return, 1..100 (default 20). action:"list_assets" — max records to return (default: all, no upper bound).
sinceNoaction:"list_assets" — ISO timestamp; only return assets created at or after this time.
actionYesWhich image/asset operation to perform. "get" requires `filename`; "view" and "asset_metadata" require `asset_id`; "convert" requires `format` plus exactly one of `asset_id`/`path`; action:"analyze_color" takes one source (`asset_id`, `filename`, or `path`); "list_outputs" and action:"list_assets" take no required parameters.
effortNoaction:"convert" — WebP only: encoder effort, 0-6.
formatNoTwo unrelated meanings, one per action — the enum is the union of both and each action accepts only its own half. action:"list_outputs" — RESPONSE SHAPE: "markdown" (default, human/agent-readable) or "json" ({images:[{filename,subfolder,kind,size,modified}]} — for app clients building pick grids). action:"convert" — REQUIRED target encoded image format: "png", "jpeg" or "webp".
patternNoaction:"list_outputs" — filter by filename pattern (case-insensitive substring match).
qualityNoaction:"convert" — encoder quality, 1-100. Applies where supported by the selected format.
asset_idNoAsset id returned by action:"list_assets" or job completion. REQUIRED for actions "view" and "asset_metadata". OPTIONAL for "convert" (provide exactly one of asset_id or path) and action:"analyze_color" (one of asset_id, filename, or path).
filenameNoOutput image filename, e.g. PulID_Klein_00001_.png. REQUIRED for action:"get". OPTIONAL for action:"analyze_color", where it is one of the three ways to name a source (pair it with subfolder/type).
losslessNoaction:"convert" — WebP only: write lossless WebP.
out_pathNoaction:"convert" — optional output path under COMFYUI_PATH/output where the converted image should be written.
save_dirNoaction:"get" — absolute local directory to save the file in. Defaults to a 'comfyui-images' folder inside the platform temp directory (os.tmpdir()), which is created if missing. A RELATIVE value is resolved against this MCP process's working directory, which is the client's choice and may not be writable. On Windows a drive-less path like \out is resolved against this process's CURRENT DRIVE, not a drive you chose. Prefer a fully-qualified path (C:\... or \\server\share); the returned 'Saved to:' line always names the resolved absolute path.
histogramNoaction:"analyze_color" — also return an overlaid R/G/B/luma histogram PNG for visual confirmation (default false).
subfolderNoSubfolder within the directory, if any (default empty). Used by action:"get" and by action:"analyze_color" when the source is a `filename`.
progressiveNoaction:"convert" — JPEG only: write a progressive JPEG.
reference_pathNoaction:"analyze_color" — optional reference image to shot-match against; returns target−reference deltas for contrast, black/white points, saturation, and per-channel means.
max_preview_bytesNoaction:"get" — ceiling on the base64 payload returned INLINE (default ~16MB). The file saved to disk is never affected. Lower it when your client rejects or truncates large tool results; the reply says when it downscaled and by how much.
max_preview_dimensionNoaction:"get" — ceiling on the inline preview's longest side in pixels (default 4096). Applies even when the byte budget is satisfied, since some consumers reject by dimension — but only for an image this server can decode; an undecodable one under the byte budget is passed through as-is. Does not affect the saved file.
Behavior5/5

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

With no annotations provided, the description carries the full transparency burden and exceeds it. It discloses read-only status, local vs. remote behavioral inversions, registry expiry/TTL, that list_outputs does not return bytes, that video/audio are saved to disk rather than inline, save_dir path resolution pitfalls (Windows drive-less paths), and preview-size downscaling. These go far beyond what a schema or annotation would capture.

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?

Although long, the description is tightly structured with a leading summary, numbered action bullets, and paragraph breaks for exceptions. Every clause transfers new information; there is no filler, tautology, or repetition of schema mechanics. The length is proportionate to the tool's genuine complexity (seven actions, remote/local differences, multiple parameter combinations).

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 20 parameters, 7 actions, no output schema, and no annotations, the description leaves little unanswered. It covers return behavior (inline image vs. saved file vs. JSON/markdown), side effects (write-back on convert), failure modes (remote listing can't confirm VHS videos), ordering semantics (newest-first), and integrations with sibling tools (chain with upload_image stage). It is self-sufficient 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 coverage is 100% and each parameter has a rich description, so the baseline is 3. The description adds extra value by organizing parameters per action, clarifying the dual meaning of the 'format' enum ('Two unrelated meanings... each action accepts only its own half'), and spelling out required versus optional combinations for each action (e.g., 'convert' requires format plus exactly one of asset_id/path). This is a meaningful layer 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 opens with a specific verb+resource ('Fetch, browse and inspect ComfyUI images and registered assets') and then enumerates seven distinct actions ('get', 'view', 'list_outputs', etc.), each with a clear verb and target. It explicitly differentiates from siblings by naming get_history and upload_image as alternatives. This is a model of 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 Guidelines5/5

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

The description gives explicit when-to-use guidance for each action, including concrete exclusions: 'Use get_history (action:"list") first to obtain the filename', 'USE THIS TO CONFIRM A VIDEO RENDER... when get_history shows the prompt done but lists no output', and remote-vs-local caveats with alternative actions ('Check a specific filename with action:"get" or upload_image instead'). It states when list_outputs should not be used (remote) and how to choose between get and view.

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