Zhenzhen Image MCP

submit_image_edit

Submits a paid asynchronous image edit job from uploaded images, auto-polls status every 90 seconds, and saves the results to disk. Add an idempotency key to prevent duplicate charges.

Instructions

提交收费异步编辑，以 image[] 上传；每90秒自动查询并落盘。可选 idempotency_key 防重。

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>",
      "model": "<model>",
      "images": "<images>"
    },
    "name": "submit_image_edit"
  }
}

Input Schema

Name	Required	Description	Default
`size`	No	可选 auto 或 WIDTHxHEIGHT；两边为16倍数、最大3840、比例不超过3:1、总像素655360..8294400。省略时不发送。
`group`	No	分组声明：默认 reverse（逆向）；仅用户明确使用官转时传 official。此字段不发送上游、不改变密钥后台分组。	reverse
`model`	Yes	GPT Image 2.5 Sunburst 非常适合对编辑精度要求极高的应用场景；GPT Image 2.5 Flare 是目前用于生成高质量图片的最快模型。模型可以接受文本和图片作为输入，然后输出相应的图片。以上为用户提供的供应商选型说明，尚未做速度或质量对比实测。请结合用户意图选择并告知所用模型。
`images`	Yes	本机绝对图片路径、公开 HTTP(S) 图片 URL 或 base64 data URL；PNG/JPEG/WebP。
`prompt`	Yes
`quality`	No
`output_dir`	No	可选绝对输出目录；默认配置目录。异步任务查询默认沿用提交目录。
`idempotency_key`	No	可选稳定幂等键；相同参数复用，参数改变拒绝，禁止换键重试未知收费结果。
`official_options`	No	仅 group="official" 可用的官转扩展参数。未声明官转时传入此对象会在收费前拒绝。

Output Schema

Name	Required	Description	Default
`cost`	No
`note`	No
`files`	No
`group`	No
`usage`	No
`reused`	No
`status`	Yes
`task_id`	No
`warning`	No
`progress`	No
`response`	No
`next_tool`	No
`output_dir`	No
`fail_reason`	No
`save_status`	No
`wait_timed_out`	No
`download_errors`	No
`idempotency_key`	No
`auto_poll_interval`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.4.0Oct 23, 2026

addedInput schema / properties / idempotency_key

Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^[A-Za-z0-9_-]{1,128}$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "可选稳定幂等键；相同参数复用，参数改变拒绝，禁止换键重试未知收费结果。",
+  "title": "Idempotency Key"
+}

addedOutput schema / properties / auto_poll_interval

Added value: +{
+  "title": "Auto Poll Interval",
+  "type": "integer"
+}

addedOutput schema / properties / idempotency_key

Added value: +{
+  "title": "Idempotency Key",
+  "type": "string"
+}

addedOutput schema / properties / reused

Added value: +{
+  "title": "Reused",
+  "type": "boolean"
+}

First observedv0.3.0Oct 20, 2026

TDQS

A3.8/5.0

Behavior4/5

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

The description adds important behavior beyond the annotations: the operation is paid, asynchronous, auto-queries every 90 seconds, persists results to disk, and supports an optional idempotency_key to prevent duplication. This materially helps the agent understand cost and long-running behavior, though it does not cover auth or rate-limit details.

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?

The description is compact and front-loaded: it first states the operation and upload mode, then adds auto-query/persistence behavior and idempotency. There is no wasted text.

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 9-parameter async edit tool with an output schema and mostly covered input schema, the description is complete enough on the main operational behavior. It leaves group/official_options routing to the schema, which is acceptable given the schema's parameter descriptions.

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 78%, so the schema already documents most parameters well. The description adds only minimal parameter-level meaning: image[] upload and idempotency_key for deduplication; it does not explain prompt/model/group or official_options semantics beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (submit) and resource (paid asynchronous image edit) plus the upload mechanism (image[]). It is clearly an edit tool, but it does not explicitly differentiate itself from sibling tools such as submit_image_batch, edit_image, or submit_image_generation.

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

Usage Guidelines3/5

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

The async/paid framing implies when this tool is appropriate, but there is no explicit when-to-use vs alternatives guidance, no exclusions, and no named sibling routing. The agent must infer usage from the description and schema.

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

Deploy Server