Skip to main content
Glama
Sign In
Local Image MCP

Local Image MCP

by fz-liu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

generate

Creates images from text prompts locally with Qwen-Image 2.1 through ComfyUI, then returns the saved file’s absolute path for direct access.

Instructions

用本地 ComfyUI 的 Qwen-Image 2.1 模型做文生图，返回图片绝对路径。Generate an image locally with Qwen-Image 2.1 on the local ComfyUI and return the absolute file path. 512x512、20 步在本机约 29 秒（已加载）；768×768 冷启动约 60 秒、1024×1024 已加载约 80 秒，仅为单次记录。A local test took about 29s at 512x512 warm, 60s at 768x768 cold, and 80s at 1024x1024 warm; timing varies. 超时返回 prompt_id，请用 get_result 继续查询，避免重复提交。Use get_result after a wait timeout instead of submitting again.

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>"
    },
    "name": "generate"
  }
}

Input Schema

NameRequiredDescriptionDefault
cfgNoCFG 引导强度，1..8，默认 1（Qwen-Image 官方推荐 1）。CFG scale 1..8, default 1.
seedNo随机种子 0..2^53-1；省略则随机生成，并在结果里返回实际使用的 seed（便于复现）。Seed 0..2^53-1; omit for a random one, which is returned in the result so it can be reproduced.
stepsNo采样步数，1..40，默认 20；越多越慢越细。Sampling steps 1..40, default 20.
widthNo图片宽度像素：256..1024，必须是 16 的倍数，且 width*height 不超过 1048576；默认 512。768、1024 已在 8GB 显卡上实测可用，更大面积可能显存不足。Image width: 256..1024, multiple of 16, width*height <= 1048576, default 512. 768 and 1024 are verified on an 8GB GPU; larger areas may hit OOM.
heightNo图片高度像素：256..1024，必须是 16 的倍数；默认 512。768、1024 已在 8GB 显卡上实测可用。Image height: 256..1024, multiple of 16, default 512.
promptYes正向提示词，必填，1..4000 字符。Positive prompt (required, 1..4000 chars).
return_imageNo为 true 且图片不超过 2MB 时，额外返回一个 image 内容块（base64 PNG），模型可直接看图。When true and the file is <=2MB, an extra image content block (base64 PNG) is returned.
wait_secondsNo最多等待多少秒，默认 180，上限 600。超时不算失败，返回 status=running，之后可调用 get_result 取图。Max seconds to wait, default 180, cap 600. A timeout is not an error: it returns status=running and get_result can fetch the image later.
filename_prefixNo输出文件名前缀，仅允许 [A-Za-z0-9_-]，长度 ≤40，非法字符会被替换成 _；默认 DSH_Qwen21。实际文件名还会带一个短运行 ID，避免覆盖旧图。Output filename prefix, [A-Za-z0-9_-] only, <=40 chars, illegal characters become _; default DSH_Qwen21.
negative_promptNo负向提示词，可选，默认空字符串。Negative prompt (optional, default empty).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.2

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does much of it: latency benchmarks by resolution ('512x512 warm ~29s, 768x768 cold ~60s, 1024x1024 warm ~80s'), timeout-is-not-failure semantics, the short run-ID suffix that prevents overwriting prior images, and the 2MB cap on the extra image block. Gaps remain around prerequisites (ComfyUI must be running), VRAM contention, and whether requests queue, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is well front-loaded — capability, then timing, then the timeout fallback — and every claim is relevant. However, the full bilingual duplication roughly doubles the token cost for zero added information, which is a real efficiency penalty against the conciseness bar.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, no-output-schema, no-annotation generation tool, the description covers the essentials: what is produced (absolute path, optional inline image block), how long it takes, and how to recover from a timeout. Only the operational prerequisites (a live ComfyUI instance, GPU availability) are left implicit.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already explains every one of the 10 parameters, making 3 the baseline. The description does add a little meaning by tying resolution choices to measured timings and OOM risk, but it gives no per-parameter guidance beyond what the schema states.

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 ('文生图 / Generate an image locally with Qwen-Image 2.1 on the local ComfyUI') plus the return contract ('返回图片绝对路径 / return the absolute file path'). An agent can distinguish it immediately from the polling/utility siblings get_result, status, and free_vram.

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 an explicit routing rule for the main failure mode: 'Use get_result after a wait timeout instead of submitting again', naming the sibling and the condition that selects it. It stops short of other when-to guidance an agent would want — e.g. what to do on OOM (free_vram?) or whether concurrent submissions queue — so it is clear but not fully exhaustive.

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