zhenzhen-nanobanana-mcp

Submit Image Tasks

submit_image_tasks

Idempotent

Register up to 20 background image generation or edit tasks and return immediately without waiting for results. Use it for batch e-commerce image jobs, then query status and fetch saved files later.

Instructions

批量登记1–20个后台图像任务并立即返回，不等待绘图/下载（会在后台收费）。

每项task_id在checkpointer/thread_id内唯一且稳定，同内容复用；任何冲突全批不新增。每项可选model/api_format(auto)/endpoint(auto)；变体按显式resolution路由。 Flash-lite仅Gemini/Chat；nano-banana-pro仅DALL·E；gemini-nano仅DALL·E Generations/Gemini/Chat。查询get_image_tasks；queued/preparing/running是正常状态，unknown不能盲目重交。 MCP进程关闭时未发送任务可在重启后继续，已可能发送任务不自动重试。

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": {
      "checkpointer": "<checkpointer>",
      "thread_id": "<thread_id>",
      "tasks": "<tasks>"
    },
    "name": "submit_image_tasks"
  }
}

Input Schema

Name	Required	Description	Default
`tasks`	Yes
`thread_id`	Yes
`checkpointer`	Yes

Output Schema

Name	Required	Description	Default
`tasks`	Yes
`thread_id`	Yes
`next_cursor`	No
`checkpointer`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.3.1Oct 23, 2026

addedInput schema / properties / tasks / items / properties / reference_sha256

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "pattern": "^[0-9a-f]{64}$",
+        "type": "string"
+      },
+      "maxItems": 4,
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "可选，按参考图顺序提供预期SHA256，内容不符时收费前拒绝。"
+}

changedInput schema / properties / tasks / maxItems
```
Previous value: -12New value: +20
```

addedOutput schema / properties / tasks / items / properties / file_integrity

Added value: +{
+  "default": "not_checked",
+  "enum": [
+    "not_checked",
+    "verified",
+    "failed"
+  ],
+  "title": "File Integrity",
+  "type": "string"
+}

addedOutput schema / properties / tasks / items / properties / post_attempts

Added value: +{
+  "default": 0,
+  "title": "Post Attempts",
+  "type": "integer"
+}

addedOutput schema / properties / tasks / items / properties / provider_idempotency_key

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

addedOutput schema / properties / tasks / items / properties / recovery_attempts

Added value: +{
+  "default": 0,
+  "title": "Recovery Attempts",
+  "type": "integer"
+}

addedOutput schema / properties / tasks / items / properties / reference_sha256

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "title": "Reference Sha256",
+  "type": "array"
+}

addedOutput schema / properties / tasks / items / properties / safe_to_retry

Added value: +{
+  "default": false,
+  "title": "Safe To Retry",
+  "type": "boolean"
+}

changedOutput schema / properties / tasks / items / properties / status / enum

Previous value: -[
-  "queued",
-  "preparing",
-  "running",
-  "succeeded",
-  "failed",
-  "unknown",
-  "cancelled"
-]New value: +[
+  "queued",
+  "preparing",
+  "running",
+  "recovering",
+  "succeeded",
+  "failed",
+  "unknown",
+  "cancelled"
+]

First observedv0.2.1Oct 21, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that billing happens in the background (a cost side effect no hint declares), that the batch is atomic ('任何冲突全批不新增'), and that task_id is stable/idempotent within checkpointer/thread_id — consistent with idempotentHint=true. Adds model↔api_format compatibility constraints and the restart/retry boundary, none of which are derivable from readOnlyHint/openWorldHint alone.

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-loads the core contract (batch, async, returns immediately, billed in background) in line one, then adds one dense line per concern: idempotency, optional routing fields, per-model constraints, follow-up tool, failure/resume. Telegraphic but every line carries distinct operational information.

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 mutation tool with an output schema, it covers the essentials an agent needs: cost, atomicity, idempotency key, model routing, follow-up polling, and crash/retry semantics. The residue is the missing meaning of checkpointer/thread_id, without which an agent may not know what value to supply.

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?

Top-level parameters (checkpointer, thread_id, tasks) carry no schema descriptions, so the description must compensate — it does partly, defining the task_id uniqueness namespace and the optionality of model/api_format/endpoint plus the resolution-based variant routing. But it never explains what a checkpointer or thread_id is or how to choose one, which is the biggest remaining gap for a 3-required-param tool.

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 precise verb+resource+scope: batch-register 1–20 background image tasks and return immediately without waiting for generation or download. That scope (§ 20 max, async, non-blocking) is exactly what separates it from generate_images (synchronous) and wait_image_tasks, so an agent can route without opening a schema.

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?

Explicitly routes follow-up: '查询get_image_tasks；queued/preparing/running是正常状态，unknown不能盲目重交' — naming the query sibling and forbidding blind resubmission on unknown state. It also covers the restart case (unsent tasks resumable, possibly-sent tasks not auto-retried). What's missing is an explicit statement of when to prefer this over generate_images in the first place.

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