Zhenzhen Image MCP

wait_image_task

Idempotent

Poll an asynchronous image task within a bounded timeout, saving the image when it completes; if time runs out, return the task ID for a later status check.

Instructions

有界轮询，NOT_START 排队和 IN_PROGRESS 处理中继续等待，成功后落盘；只读查询有限重试计入等待时限。超时返回 task_id/wait_timed_out，云端任务继续；可稍后再次查询。

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": "wait_image_task"
  }
}

Input Schema

Name	Required	Description
`task_id`	Yes
`output_dir`	No	可选绝对输出目录；默认配置目录。异步任务查询默认沿用提交目录。
`poll_interval`	No
`timeout_seconds`	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.

Changed5 schema fields changedv0.4.0Oct 23, 2026
- changedInput schema / properties / poll_interval / default
```
Previous value: -5New value: +90
```
- changedInput schema / properties / poll_interval / maximum
```
Previous value: -60New value: +300
```
- 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.5/5.0

Behavior4/5

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

Adds meaningful behavior beyond the annotations: bounded polling, retries counting toward the wait budget, file persistence on success, and the timeout return shape (task_id/wait_timed_out) with the cloud task continuing. This is consistent with readOnlyHint=false, since the tool writes output to disk. No contradiction.

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?

Compact and front-loaded with the core concept ('有界轮询'), then the status behavior, then the timeout outcome. Dense but every clause carries information; no filler.

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 polling tool with an existing output schema, it covers the key unknowns: status handling, persistence, and timeout semantics. The primary residual gap is the undocumented poll/timeout parameters, which is a schema-level shortfall more than a description one.

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 coverage is only 25% (only output_dir documented); poll_interval and timeout_seconds lack any unit/range/meaning in both schema and description. The description alludes to a wait time limit ('计入等待时限') but does not map it to the timeout_seconds or poll_interval parameters.

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 operation (bounded polling of an image task) with concrete statuses (NOT_START, IN_PROGRESS) and outcome (file written to disk on success). Clear verb+resource, though it never names the sibling get_image_task or get_batch_image_task to disambiguate when simply querying once is enough.

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?

Implies when to use it by describing status transitions that trigger continued waiting and the timeout path ('cloud task continues; can query again later'). However, it never explicitly states when to choose this over a plain get_image_task poll, leaving the agent to infer the trade-off.

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

Deploy Server