Zhenzhen Image MCP

get_image_task

Idempotent

Check an image task's queue, progress, failure, or success status, retry transient query failures up to three times, and optionally save successful images without resubmitting the task.

Instructions

查询 NOT_START（排队）/IN_PROGRESS/FAILURE/SUCCESS；暂时性查询故障最多尝试3次。save=true 时成功图片自动落盘；false 仅查询。不重新提交。

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": {
      "task_id": "<task_id>"
    },
    "name": "get_image_task"
  }
}

Input Schema

Name	Required	Description
`save`	No
`task_id`	Yes
`output_dir`	No	可选绝对输出目录；默认配置目录。异步任务查询默认沿用提交目录。

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.

Changed3 schema fields changedv0.4.0Oct 23, 2026

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.6/5.0

Behavior4/5

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

The description explains why readOnlyHint=false despite this being a status check: with save=true the successful images are written to disk, while save=false is query-only. It also discloses internal retry behavior (up to 3 attempts on transient query failures), which is context the annotations cannot express. It stops short of saying what happens to files when a task has failed or whether repeats overwrite previously saved output.

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?

Three short clauses, front-loaded with the observable states, then the retry guarantee, then the save semantics. Zero filler; the telegraphic semicolon style loses a little readability but nothing is redundant.

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

Completeness3/5

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

An output schema exists, so return values need no explanation, and the annotations plus the save note cover the safety profile. What is missing is differentiation from wait_image_task/get_batch_image_task and any statement of what happens when the task is FAILURE (whether an error or a status object is returned), which matters for a polling tool.

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 coverage is only 33% — task_id and save carry no schema description — so the description does real work by defining save's true/false semantics. task_id is only implicitly covered ('查询' a task). output_dir is documented in the schema but not tied to save behavior in the description, leaving one gap on each side.

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?

States a specific verb (查询/query) and resource (task status) and enumerates the four terminal/non-terminal states it can return. It also explicitly rules out resubmission, which separates it from the submit_* siblings, but it does not distinguish itself from wait_image_task or get_batch_image_task, which an agent must still disambiguate by name alone.

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 '不重新提交' clause gives one clear exclusion (this is a poll, not a submit), and the retry note implies it is safe to call repeatedly while a task is queued. However, there is no guidance on when to prefer wait_image_task (presumably blocking) or get_batch_image_task over this tool, so the choice among polling siblings is left to inference.

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

Deploy Server