Zhenzhen Image MCP

get_batch_image_task

Idempotent

Fetches and saves asynchronous batch image results using original checkpointer, thread ID, and task ID; returns local status if supplier ID is missing and uses limited read-only retries.

Instructions

按原(checkpointer,thread_id,task_id)查询供应商异步结果并自动落盘；只读HTTP有限重试。没有供应商编号时返回本地状态，不重新提交。云端失败为工具错误；检查 result.save_status。

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_id": "<task_id>"
    },
    "name": "get_batch_image_task"
  }
}

Input Schema

Name	Required	Description
`save`	No
`task_id`	Yes	批量提交时指定的原始 task_id。
`thread_id`	Yes	稳定的本地检查点命名空间/会话键，1–128字符。
`output_dir`	No	可选绝对输出目录；默认配置目录。异步任务查询默认沿用提交目录。
`checkpointer`	Yes	稳定的本地检查点命名空间/会话键，1–128字符。

Output Schema

Name	Required	Description	Default
`error`	No
`group`	Yes
`result`	No
`reused`	Yes
`status`	Yes
`task_id`	Yes
`warning`	No
`thread_id`	Yes
`output_dir`	Yes
`checkpointer`	Yes
`provider_task_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.4.0Oct 23, 2026
- addedOutput schema / $defs / ImageResult / properties / auto_poll_interval
```
Added value: +{
+  "title": "Auto Poll Interval",
+  "type": "integer"
+}
```
- addedOutput schema / $defs / ImageResult / properties / idempotency_key
```
Added value: +{
+  "title": "Idempotency Key",
+  "type": "string"
+}
```
- addedOutput schema / $defs / ImageResult / 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 meaningful behavior beyond the annotations: limited read-only HTTP retries, automatic local persistence, local-status fallback without resubmission, and checking result.save_status. This is consistent with readOnlyHint=false because the tool writes to disk despite using read-only upstream HTTP calls.

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 states the lookup key and action first, then adds retry, fallback, and error guidance. Every clause carries useful 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?

Given the annotations, high schema coverage, and presence of an output schema, the description is largely complete. It covers persistence, retry limits, local fallback, error handling, and save_status, though it could be clearer about sibling-tool selection.

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 high at 80%, so the schema already carries most parameter meaning. The description adds that the three required keys identify the original submission and that results are auto-saved, but it does not clarify save or output_dir behavior beyond the schema.

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 clearly states a specific verb and resource: query a supplier asynchronous result by the original (checkpointer, thread_id, task_id) and persist it locally. It does not explicitly contrast itself with siblings such as get_image_task or wait_image_task, so it falls short of a 5.

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?

It gives useful usage context by saying that without a supplier ID it returns local status and does not resubmit, and that cloud failure is a tool error. However, it does not explicitly say when to use this tool versus sibling retrieval or wait tools.

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

Deploy Server