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

没有注解，因此描述承担全部说明责任；它很好地说明了关键的无副作用特性（同步返回、不实际生成、不扣费）。但它没有提及什么都不返回、是否校验参数，或者 estimate 与 generate 的校验是否不同。

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

两句话，句句有分量，先说明“做什么”和“不做什么”。大小合适。“等参数”的措辞略含糊，但影响不大。

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

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

对于一个包含嵌套对象的 4 参数估算工具，安全特性和使用时机都已覆盖，但描述从未说明返回值的形态（例如返回单个积分总数，还是按模型/尺寸拆分的明细），也没有输出 schema 来弥补这一点。

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

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

Schema 覆盖率为 50%；描述将参数概括为“模型、尺寸、宽高比”，但模型枚举的 schema 已经通过按模型给出积分成本和选型建议承担了大部分工作。描述从未说明为什么一个不生成内容的工具必须填写 prompt——这是 Agent 会注意到的实际缺口。

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

特定动词（预估）+ 特定资源（生成图片所需的积分），并明确排除了实际生成（“不实际生成图片、不扣除积分”），从而与 generate_image 区分开来。Agent 无需查看 schema 即可知道此工具返回什么。

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

“适合在批量生成或使用 4K 前先确认成本”给出了具体的使用场景，模型参数的 schema 也指引 Agent“先用 estimate_credits 查询”。它没有明确点出生成对应的操作（generate_image），但排除性陈述传达了这层意思。

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

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

With no annotations present, the description carries the full burden and does substantial work: it discloses the default disk side effect (saving full-resolution originals), the bounded preview returned to MCP, structured metadata plus a JSON text fallback, automatic async handling for 4K, and that providers never need to be specified. It does not mention auth requirements, credit costs, or whether files are overwritten on repeat calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences, front-loaded with the tool's scope before moving to output behavior and model selection; nothing is redundant. Density works against it slightly — file handling, preview format, async behavior, and model selection are all packed without visual separation, making it easy to skim past the async-wait detail.

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

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

Given seven parameters, nested reference-image objects, enums, and an output schema, the description covers the pieces an agent most needs: what gets saved where, what comes back, and that long-running 4K calls resolve internally. The main omission is any mention of credit consumption or a pointer to estimate_credits, which matters for a paid generation tool.

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

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

Schema coverage is 71% and the schema itself is unusually rich — per-model cost and use-case guidance, outputMode semantics, saveDir defaults, and referenceImages formats are all documented inline. The description adds only that models are chosen via the model parameter and no provider field is needed, which is marginal value over the schema and leaves prompt, imageConfig, and timeoutSeconds untouched at the description level.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise scope — text-to-image, image-to-image, and image editing in one tool — so the agent knows exactly which operation family this covers. It implicitly differentiates from the task-polling siblings by stating 'no manual polling needed', but never names get_generation_task or list_generation_tasks, so sibling routing is only inferable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied through the three modes (text-to-image / image-to-image / editing) and the note that 4K runs async internally without polling, which steers the agent away from a poll loop. However, there is no explicit statement of when NOT to call this tool, no pointer to estimate_credits before spending credits, and no reference to the task-listing siblings as an alternative view.

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

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

No annotations are supplied, so the description carries the burden — and it does disclose the return contract: a unified structured envelope, a size-bounded MCP image preview, and the original image URL. That 'bounded preview' detail is genuinely non-obvious behavior. It does not address failure paths (failed task, unknown taskId) or auth/rate limits, so it falls short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with purpose, then return shape, then the recovery workflow. Nothing is repeated from the schema or annotations and no sentence is filler.

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

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 less prose, yet the description still sketches the envelope and preview/URL split. Combined with the generate_image timeout flow, an agent has enough to call it correctly; only the behavior for a failed or expired task is unaddressed.

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

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

Schema description coverage is 0%, so the single required taskId is only explained by the description — and it does explain provenance: it is the taskId returned by generate_image after a wait timeout. No format or length constraints are restated, but the origin of the value is the piece the schema cannot convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource in the first clause (query image generation task status and result), and the singular 'task' framing plus the explicit hand-off from generate_image separates it from list_generation_tasks. An agent can tell what this retrieves without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

States a concrete trigger and alternative: after generate_image times out, call this with the returned taskId to get the result. That is a clear when-to-use. It stops short of an exclusion (e.g. do not use this to enumerate tasks — use list_generation_tasks instead), so it is not a full when/when-not statement.

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

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

No annotations exist to lighten the description's burden, but the description does disclose which fields come back: monthly, permanent, and limited-time credits, freeUsages, and reset time. It does not mention side effects (a get implies none), but it also fails to mention rate limits, caching, or whether the values are live. That is acceptable disclosure for a read-only getter, but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one dense, front-loaded sentence with no filler. The parenthetical breakdown of credit types is compact and informative rather than redundant.

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

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

Because there is no output schema, the description must convey the return shape; it lists the key fields, including freeUsages and reset time, which are not obvious from the name alone. For a zero-parameter getter, this is nearly complete; only output formatting and freshness are unstated.

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

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

The schema defines zero parameters, so the baseline score is 4; there is nothing for the description to disambiguate. The description correctly implies the tool takes no arguments and acts on the caller's account.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb (获取) and resource (subscription info for the current API Key account), and it enumerates the returned data: subscription status, credits split by type, freeUsages, and reset time. It does not explicitly distinguish itself from siblings such as estimate_credits, which also deals with credits, so it stops 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states what the tool returns but never when to call it instead of alternatives; for example, it does not clarify whether this is the way to check the balance before generate_image or how it differs from estimate_credits. The API-Key scoping is mentioned, but no exclusions or naming of alternatives are provided.

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

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

With no annotations, the description carries the full burden and does disclose two genuine behavioral traits beyond the schema: results are scoped to the current API Key's own tasks, and output is sorted by creation time descending. It omits what each returned task contains and whether pagination metadata is included, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that states scope, ordering and filtering in order of importance with no redundant restatement of the name. Nothing can be trimmed without losing information.

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

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

For a 3-parameter read-only list tool with a fully documented schema this covers the essentials (who, order, filter), but with no output schema present the description gives no hint about the shape of returned task records or pagination fields, leaving an agent to discover the response empirically.

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

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

Schema description coverage is 100% — page, pageSize and the status enum are all documented in the schema, so baseline is 3. The description only echoes the status-filter concept and adds no format or default detail beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-resource pair (返回…图片生成任务历史) and adds scope (当前 API Key 用户) and ordering (按创建时间倒序), so an agent can tell this is a list/history operation distinct from the sibling get_generation_task. It stops short of explicitly naming that sibling as the single-task alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: '任务历史' plus '可按状态过滤' suggests browsing past tasks, and the sibling name get_generation_task implies the single-record counterpart, but the description never says when to prefer one over the other or what prerequisites exist.

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