zhenzhen-nanobanana-mcp

Cancel Image Tasks

cancel_image_tasks

Idempotent

Cancel specified image tasks by ID; queued/preparing tasks won't generate, while running tasks stop local waiting and are marked unknown without guaranteed remote stop or refund.

Instructions

取消指定任务；queued/preparing不发图，running只停止本地等待并标unknown，不保证远端停止/退款。

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

Input Schema

Name	Required	Description	Default
`task_ids`	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.

Changed7 schema fields changedv0.3.1Oct 23, 2026

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

B3.4/5.0

Behavior4/5

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

Annotations already declare idempotent=true and destructiveHint=false. The description adds substantial context beyond that: queued/preparing tasks will not be dispatched, running tasks only stop local waiting and are marked unknown, and remote stop or refund is not guaranteed. This is exactly the kind of limitation an agent needs before invoking a cancel operation.

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 a single front-loaded sentence with no wasted clauses. The cancellation action comes first, followed by the critical behavioral caveats in a compact semicolon-separated structure.

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

Completeness2/5

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

The description covers state-dependent cancellation behavior well, and the output schema means return values need not be explained. However, for a tool with three required parameters and 0% schema description coverage, the absence of thread_id and checkpointer semantics leaves the definition incomplete for correct invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry the burden for three required parameters. 'Specified tasks' loosely maps to task_ids, but thread_id and checkpointer are not explained at all, leaving most parameter meaning undocumented.

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 opens with a specific verb and resource: cancel specified tasks. It is clear this is the inverse of retry_image_tasks, but it does not explicitly name or differentiate itself from siblings in the text.

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?

Cancellation is implied as the action, and the description explains state-specific outcomes for queued/preparing/running tasks. However, it does not explicitly say when to prefer this tool over alternatives such as retry_image_tasks or wait_image_tasks.

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