Skip to main content
Glama

image_generate

Renders a text prompt into one or more image files saved locally. Supports adjustable resolution (up to 4K), quality levels, and batch generation of up to 10 candidates — no reference image needed.

Instructions

文本生成图像(text-to-image)。米醋代理 + gpt-image-2 系列。

[WHAT] 把一段文字 prompt 渲染成 1 张或 N 张图像,落盘到本地。

[WHEN TO USE]

  • 用户要"画 / 生成 / 创建一张图"且没有提供任何参考图 → 用此 tool。

  • 如果用户提供了 1 张参考图要"修改 / 编辑 / 替换某部分" → 改用 image_edit。

  • 如果用户提供了多张参考图要"按它们的风格画一张新的" → 用 image_multi_reference。

  • 如果不知道怎么选 size:先调 server_info() 看 recommended_sizes。

[SIZE 选取建议]

  • 默认 None:MCP 自动从 prompt 关键字推断(4K/UHD → 3840x2160;1080p/2K → 2048x1152; 正方形/logo/头像 → 1024x1024;竖屏/9:16 → 1024x1536;横屏/16:9 → 1536x1024 等)。 推断不出来 fallback 1024x1024。

  • 强烈推荐:如果你(LLM)已经从用户消息读出确定的 size 偏好,直接显式传 size,比关键字推断准。

  • 用户提到"高清/4K/海报/壁纸" → "3840x2160"(横)或 "2160x3840"(竖),自动用 gpt-image-2-openai。

  • 用户提到"FullHD/1080p/横屏视频封面" → "2048x1152"(横)或 "1152x2048"(竖); 这两个尺寸均满足当前 16 像素对齐和总像素约束。

  • W 与 H 必须都是 16 的倍数;最长边 ≤3840;长宽比 ≤3:1;总像素 655,360-8,294,400。

  • 2K/4K 自动走高质量线路:≥2K 自动切 gpt-image-2-openai。2026-08-14 实测其 1536×1024、 2048×1152、3840×2160 均按请求像素返回;gpt-image-2 的自定义宽高可能被后端重映射。

[PROMPT 写法建议]

  • 中英文混合可。gpt-image-2 文本渲染近完美,可大段嵌字(中英标点都行)。

  • 越具体越好:风格 / 视角 / 光线 / 主体 / 细节程度。

Args: prompt: 图像描述。1-2000 字符。例:"A minimalist sushi mascot logo, soft pastel palette". size: "WxH" 字符串或 None。留 None 让 MCP 从 prompt 推(弱 LLM 兜底用); 强 LLM 已知偏好时直接显式传更准。W 和 H 都必须是 16 的倍数。常用: "1024x1024" "1280x720" "1024x1536" "1536x1024" "720x1280" ← 1K 档 "2048x2048" "2048x1152" "1152x2048" ← 2K 档(自动 gpt-image-2-openai) "3840x2160" "2160x3840" ← 4K 档(自动 gpt-image-2-openai) 默认 None(推断后兜底 1024x1024)。 n: 张数 1-10。1K 时 N>1 自动 5 并发;≥2K 强制 N=1(代理限流)。默认 1。 model: 显式指定模型。留空时按 size 自动选(max edge ≥1600 用 gpt-image-2-openai,否则 gpt-image-2)。 可选值:"gpt-image-2"(标准线路)/ "gpt-image-2-openai"(高质量线路)。 quality: 可选质量参数:"auto" / "low" / "medium" / "high";留空则使用后端默认值。 save_dir: 输出目录。必须在安全根目录 MICU_SAVE_DIR_ROOT 之下(默认 ~/Pictures/micu-out); 传 root 之外路径会被拒。留空使用默认。 basename: 文件名前缀(不带扩展名),仅允许 [A-Za-z0-9_-.]。 含 / .. 或路径分量会被拒。默认 "gen_"。 api_key: 覆盖 MICU_API_KEY 环境变量。一般留空。 注意:base_url 已锁在启动时 env,运行期不接受 tool 参数(防 key 外泄到攻击者 host)。

Returns: dict 含以下字段: ok (bool): 至少有 1 张成功才为 True。 model (str): 实际用的模型 id。 size (str): 请求的 size。 requested_n (int): 实际生成的张数。 saved (list[dict]): 每张成功的图。每项含 path(绝对路径)/ size_bytes / actual_size(PNG header 读出的真实像素)/ actual_megapixels。 errors (list[str]): 失败请求的错误描述。 notes (list[str]): 路由 / 自动决策 / 实测尺寸偏差的说明。

Examples: # 最简:默认 1024x1024 单张 image_generate(prompt="a red apple on white")

# 4K 壁纸
image_generate(prompt="cyberpunk Tokyo at night", size="3840x2160")

# 一次出 4 张候选(1K 自动并发)
image_generate(prompt="cute sticker of a cat", size="1024x1024", n=4)

Common errors and what to do: "size W/H 必须是 16 的倍数" → 客户端入口拒;例如 1920×1080 应改为 1920×1088 或推荐的 2048×1152。 "HTTP 524: timeout" → 已自动重试 3 次仍失败,建议改小 size 或稍后再试。 "未配置 API key" → 设置 MICU_API_KEY 环境变量或传 api_key 参数。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nNo
sizeNo
modelNo
promptYes
api_keyNo
qualityNo
basenameNo
save_dirNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / quality
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Quality"
      +}
  2. First observedv0.1.0

TDQS

A4.9/5.0
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 it excels. It discloses automatic size inference from prompt keywords, fallback to 1024x1024, auto model selection based on max edge ≥1600, forced N=1 for ≥2K, 5-way concurrency for 1K with N>1, security constraints (save_dir must be under MICU_SAVE_DIR_ROOT, basename whitelist, base_url locked at startup to prevent key leakage), and measured deviations from requested sizes on certain models. It even documents retry behavior for timeouts. This is far beyond typical transparency.

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 long but extremely well-structured with clear section headers ([WHAT], [WHEN TO USE], [SIZE], [PROMPT]) and bullet points. The most critical info (what it does, when to use) is front-loaded. Examples and common errors are placed at the end where they belong. While it's verbose, every section adds distinct value – no redundant filler. The length is justified by the tool's complexity (8 params, routing logic, safety checks). It earns a 4, not 5, only because it is genuinely long and might overwhelm a quick scan.

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?

Despite having an output schema (returns dict), the description still explains each return field (ok, model, size, requested_n, saved, errors, notes) and their semantics, which is helpful. It covers the full decision tree (size selection, model routing, concurrency), all constraints (16-pixel multiples, aspect ratio limits, pixel bounds), and common error scenarios with remediation. It also includes practical examples and edge-case notes (like 1920×1080 → 2048×1152). For a tool with this many parameters and automatic behaviors, the description is remarkably complete.

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% (all 8 parameters lack schema descriptions), so the description must provide full parameter semantics – and it does. Each parameter gets its own line with default, constraints, and examples: prompt with character limit and example, size with valid formats and auto-inference logic, n with range and concurrency implications, model with optional values and selection rule, quality with allowed values, save_dir with security path restriction, basename with regex whitelist, and api_key with env override note. The description fully compensates for the schema gap.

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 clear verb and resource: '文本生成图像(text-to-image)' – it generates images from text prompts and saves them to disk. It directly distinguishes itself from siblings by stating that image_edit is for editing with a reference image and image_multi_reference is for style transfer from multiple references. An agent can unambiguously route to this tool versus alternatives.

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 [WHEN TO USE] section explicitly states when to use this tool ('画/生成/创建一张图' without reference), names two sibling alternatives with exact conditions (image_edit for single ref, image_multi_reference for multiple refs), and points to server_info for size selection when uncertain. It also gives negative guidance (use other tools when refs are provided), making the routing decision completely deterministic.

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