Skip to main content
Glama

Generate image (ComfyUI)

generate_image

Creates images from text prompts with a local ComfyUI diffusion model, including reference-guided edits, transparent cutouts, and reproducible seeds; saves PNGs plus prompt and settings metadata.

Instructions

Generates an image with a diffusion model running in ComfyUI on a GPU machine. No API key or per-image cost. Use it for design mockups, reference-guided variations and edits (pass refs), and finished raster assets such as illustrations, photos, textures and transparent cutouts. The PNG is written to out, relative to the project root, with a <out>.json sidecar recording the prompt, seed and settings. The image is also returned in the result when it is small enough. Each call takes roughly 20-120 s, so make calls one at a time. Local models render small text poorly: describe layout, hierarchy, palette, type character and imagery, keep quoted copy to short headlines, and do not rely on body text.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "prompt": "<prompt>",
      "out": "<out>"
    },
    "name": "generate_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
outYesOutput .png path relative to the project root, e.g. mocks/hero-a.png
refsNoReference image paths (project-relative), e.g. a screenshot or a crop. Uses the edit workflow.
seedNoFix the seed to make a variation reproducible.
sizeNoWIDTHxHEIGHT. Default 1536x1024. Large sizes are scaled down to the configured megapixel cap. Edit workflows may size from the reference instead.
promptYesFull image prompt. Lead with structure/composition, then style, palette, type character.
negativeNoNegative prompt, if the workflow uses one.
backgroundNotransparent = run background removal and return a PNG with alpha (for cutouts).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.7/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 and does so: no API key or per-image cost, PNG written to `out` with a `<out>.json` sidecar, image returned inline only when small, 20-120 s latency, and a serial-call requirement. These are real behavioral facts an agent cannot get from the schema, and none contradict anything.

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?

Front-loaded with the core action and scope, then cost, then output conventions, then latency constraint, then prompting advice — each sentence adds a distinct operational fact. No filler or self-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?

For a 7-parameter generation tool with no output schema, the description covers what is produced (file path, sidecar, conditional inline image), how long it takes, and how to phrase prompts. Nothing an agent needs to invoke it correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond it: `refs` signals the edit workflow and variation behavior, and `out` is clarified as project-root-relative with an accompanying JSON sidecar. The prompt-craft guidance reinforces how to fill `prompt` rather than merely restating 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?

States a specific verb and resource ('Generates an image') plus the execution context ('diffusion model running in ComfyUI on a GPU machine'), which immediately separates it from the sibling image_backend_status. The scope is further narrowed to raster asset generation, so an agent knows exactly what this tool produces.

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?

Gives concrete usage contexts — design mockups, reference-guided variations/edits via `refs`, and finished raster assets — plus an operational constraint ('make calls one at a time') and an explicit limitation (small text renders poorly). It does not explicitly exclude scenarios or contrast against the one sibling, so it stops 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.

Deploy Server

Other Tools