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

Annotations cover the safety profile (openWorldHint, idempotentHint, non-destructive), but the description adds real context beyond them: it validates specific formats, persists to disk, returns an absolute path, and explicitly notes it will not carry the vendor API Key. That security disclosure is genuinely useful. It stops short of describing failure modes or overwrite behavior.

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 with no filler; the core action comes first and the security caveat is a tight trailing clause.

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 no explanation, and annotations cover safety. Combined with format-validation and no-API-key disclosures, the description is nearly complete; only edge behaviors (overwrite, network failure) are absent.

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 100%, so url and output_dir are already fully documented, including the default-directory and async-task-inheritance behavior. The description adds little parameter meaning beyond restating that output goes to disk, so baseline 3 is appropriate.

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?

States a specific verb (下载/download) and resource (图片/image) plus the scope of what happens (validate PNG/JPEG/WebP, write to disk, return absolute path). This clearly distinguishes it from the sibling generation/edit tools, which produce images rather than fetch them.

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 implies the use case (fetch an image from a URL) but never states when to use this versus generate_image or edit_image, nor any prerequisites or exclusions. Usage is inferable but not guided.

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?

Annotations already declare a non-destructive, open-world write operation, so the bar is lower; the description still adds material context: the call is synchronous/blocking, it persists output to disk, and it is billed ('收费'). Permissions or concurrency limits are not covered, but cost and side-effect disclosure go beyond the annotations.

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 clauses, front-loaded with the core purpose and no filler. It is efficient and readable, though the terse style leaves several questions unanswered rather than balancing brevity with completeness.

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 no explanation, and the schema documents most parameters. However, for a billed mutation with 8 parameters and an official_options gate, the description omits the async-vs-sync decision and the consequences/placement of written files, leaving it only minimally adequate.

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 75% and the schema itself carries detailed prose for size, group, model, images, and official_options. The description only echoes the multi-image upload format (calling it image[] where the schema field is 'images') and repeats the Sunburst model advice already present in the model property description, so it adds little.

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?

States a specific verb+resource (synchronous image editing) plus a distinctive behavior (writes result to disk), which separates it from the async submission siblings such as submit_image_edit. It does not explicitly name a sibling, but '同步' clearly contrasts with the submit/poll tools.

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?

Gives one concrete routing hint ('high editing-precision scenarios → Sunburst') and an upload convention for multi-image input, but never says when to prefer this over generate_image or submit_image_edit, nor when-not to use it. Usage is implied by the synchronous nature rather than stated.

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?

Annotations cover the safety profile (readOnly false, openWorld true, non-idempotent, non-destructive), and the description adds traits they do not carry: the call is billed, POST is not automatically retried, and output is persisted to disk. The retry and billing notes are operationally important for a paid, non-idempotent call.

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?

Four compact clauses lead with the core operation, then routing, then cost/retry behavior — well front-loaded with no filler. The phrase "默认逆向五参数" is too compressed to decode, which is the one structural weakness.

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 an 8-parameter synchronous generation tool with an output schema, the description covers sync execution, disk persistence, group routing, and billing. It omits how the sync path relates to the sibling async/batch submission tools and gives no guidance on the images input beyond the 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 description coverage is 63%, and the schema itself richly documents size, images, model, and official_options. The description adds only the group-default rule and the fact that official_options is rejected pre-billing without group=official; "默认逆向五参数" is opaque and adds little usable meaning.

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?

"同步生成并落盘" gives a specific verb (generate), a modality (synchronous), and a side effect (writes to disk), which separates it from the async submit_* siblings and from edit_image. However it never names those siblings explicitly, so the agent must infer the distinction from the word "同步" alone.

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?

It states the routing rule for the group parameter (default reverse; official only when the user explicitly wants the official route), which is real when-to-use guidance. It does not, however, say when to pick this tool over submit_image_generation or submit_image_batch, leaving the sync-vs-async choice to inference.

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?

Adds real behavior beyond the annotations: read-only HTTP with bounded retries, automatic write-to-disk, local-status fallback without resubmission, and that cloud failure surfaces as a tool error monitored via result.save_status. This meaningfully explains why readOnlyHint is false despite read-only upstream calls. It stops short of describing timing/polling semantics.

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?

Front-loads the operation and keying inputs, then packs retry, fallback, and error-handling notes into two dense clauses. No filler, though the second half is run-on enough that the error-handling guidance is easy to skim past.

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 not be enumerated, and the description correctly points at result.save_status for the one field that matters. Persistence, retry, fallback, and error semantics are all covered; polling/wait behavior relative to wait_image_task is the only notable omission.

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 80%, so the per-parameter docs already carry most weight (baseline 3). The description contributes the non-obvious constraint that all three keys must be the ORIGINAL values from submission, not arbitrary IDs, and links the save/output_dir behavior to 'automatic persistence'.

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?

States a specific verb and resource: query the supplier's async result keyed by the original (checkpointer, thread_id, task_id) triple, with automatic persistence. It implicitly separates itself from the submit_* siblings by noting it never resubmits, but it never names wait_image_task or get_image_task directly, so sibling differentiation is only partial.

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?

Gives one useful conditional: when no supplier ID is present it returns local status instead of resubmitting. It also tells the agent where to look on failure (result.save_status). However, it never says when to prefer this over wait_image_task or get_image_task, so the routing guidance is implied rather than explicit.

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?

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety bar is low. The description still adds value by disclosing that reads are local/free, hit no provider, and return 'last observed' (i.e. possibly stale) state rather than live data.

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 with semicolon-separated clauses; the scoping statement ('本地') and the negative boundaries are ordered sensibly. No filler, though the three negated verbs could be tightened.

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 no explanation, and annotations cover the safety profile. The description supplies enough to call it correctly; only an explicit sibling reference is absent.

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 100% and both required params (thread_id, checkpointer) carry their own pattern and length docs. The description adds no parameter-level detail, so this is the baseline 3 where the schema does all the work.

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?

States a specific verb and resource ('免费读取本地持久化检查点') and enumerates what is restored (task_id/provider_task_id/最后观察状态). The negations ('不查询供应商、不提交、不等待成图') implicitly separate it from wait_image_task and submit_image_batch, but no sibling is named explicitly, so differentiation is inferred rather than direct.

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?

Gives clear context ('免费…本地持久化' implies the cheap cached path) plus explicit when-not boundaries: it does not query the provider, submit, or wait. What's missing is an explicit positive alternative (e.g. 'for live status use get_batch_image_task'), so the agent must infer the switch condition.

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?

Annotations already cover safety/idempotency (idempotentHint=true, destructiveHint=false), and the description adds real behavior beyond them: up to 3 retries on transient query failures, and disk writes on save=true (consistent with readOnlyHint=false). It stops short of describing failure semantics or what happens when save fails.

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 tight clauses, front-loaded with the query purpose, then retry behavior, then the save contract. No filler and every clause carries 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?

An output schema exists so return values need not be explained, and the description covers states, retry behavior, and the save side-effect. It is nearly complete for a single-task query; only explicit sibling routing (vs wait_image_task) is missing.

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 only 33%, so the description must compensate, and it does explain the most consequential parameter: save=true persists images, false queries only. task_id is self-evident and output_dir is already documented in the schema, so the remaining gap is minor.

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?

States a specific verb and resource (query an image task) and enumerates the possible states (NOT_START/IN_PROGRESS/FAILURE/SUCCESS), which pins down the resource precisely. It also clarifies it does not resubmit, which separates it from the submit_* siblings, but it does not directly contrast with wait_image_task or get_batch_image_task.

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?

Gives conditional usage for save=true (auto-persist images) vs false (query only) and notes the no-resubmit contract, which implies the right context. However it never names or contrasts the obvious alternatives wait_image_task and get_batch_image_task, so the when-to-use decision is only implied.

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?

Annotations already declare readOnly, idempotent, and closed-world (openWorldHint=false), so the safety profile is partly covered. The description adds genuinely new behavioral facts: it only checks whether a key exists, never displays the key, and never calls the cloud – useful privacy/offline context beyond the structured hints.

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 dense sentence, front-loaded with the capability and then the behavioral guarantees. Every clause earns its place; only minor readability cost from packing two ideas into one sentence.

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 no explanation. For a zero-parameter read tool, the description covers purpose and the key behavioral constraints; only explicit usage guidance is missing.

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 tool takes zero parameters, so the baseline is 4; the schema is empty and needs no elaboration. The description correctly focuses on outcome behavior rather than invented parameters.

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 states a concrete deliverable: free local model selection suggestions plus configuration status. It is clearly distinguishable from the sibling image-generation tools, though the wording ('guide') is slightly abstract about exactly what content is returned.

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 only implied – an agent can infer this is for choosing/configuring a local model, but there is no explicit when-to-use or when-not, and no named alternative or prerequisite. Adequate but with a clear gap.

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?

Goes well beyond the annotations by disclosing that this is a paid operation, that it is fire-and-return async, that identical (checkpointer, thread_id, task_id) plus parameters reuse records, that parameter conflicts are rejected pre-submission, and that uncertain submissions are never auto-resent. This is rich behavioral context and is consistent with idempotentHint=true.

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 compact paragraph with the core action front-loaded; every clause (async return, dedup key, conflict rejection, no auto-resend) earns its place. Slightly dense/run-on but efficient.

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 not be explained, and the description covers the async lifecycle, deduplication and conflict behavior an agent most needs. Remaining gaps are the per-task field semantics rather than anything blocking correct invocation.

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?

With schema coverage at 50%, the description adds real meaning by explaining the reuse key formed from checkpointer, thread_id and task_id, and by stating the default concurrency (matching max_concurrency). However it does not describe the per-task fields (task_id, prompt, model, operation) or how tasks are structured, so it only partially compensates.

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?

States a specific verb (submit) and resource (1–10 async paid generation/edit tasks) with scope (batch, concurrency default 3). It implies an async batch distinct from the single-image siblings but never names an alternative, so differentiation is left to inference.

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 async contract ('returns on task IDs, does not wait for image completion') implicitly tells the agent to follow up with wait_image_task/get_image_task, but there is no explicit when-to-use/when-not guidance and no named alternative against submit_image_generation or submit_image_edit.

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?

Annotations already declare non-read-only, non-idempotent, open-world. The description adds genuinely new context: the call is paid (收费) and asynchronous, uploads via image[], returns a task_id, and must be followed by a query/save step. Cost and the async contract are material facts not carried by the annotations.

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 dense sentence with the operation and the follow-up contract front-loaded; nothing is padded. The mixed Chinese/English and URL-fragment style ('POST edits?async=true') cost a little clarity for no gain.

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-value detail is not required, and the description does name task_id. However, for an 8-parameter paid async tool with several siblings that also submit or edit images, it omits the sync-vs-async decision and lifecycle guidance an agent needs to call the right 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 75% and the schema descriptions for size, group, model, images, output_dir, and official_options are already detailed. The description only echoes the image[] upload field and adds nothing about the other parameters, so it does not compensate for the remaining gap — baseline 3 applies.

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?

States a specific verb + resource (submit an async paid image edit via image[] upload) and notes the return value (task_id) and follow-up step. An agent can distinguish it from submit_image_generation/submit_image_batch, though the terse mixed-language phrasing ('POST edits?async=true') relies on prior knowledge of the API shape.

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?

Implies a workflow — submit, then '查询并落盘' (query then save to disk) — which points at the get_image_task/wait_image_task siblings. But it never explicitly says when to prefer this async submission over the sync edit_image or over submit_image_batch, so the choice among 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.

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

Annotations declare non-read-only, open-world, non-idempotent, non-destructive, but the description adds genuinely non-obvious context: the call is billed ('收费'), it returns a task_id immediately rather than the image, and persistence only happens if the agent keeps querying. This is real behavioral value beyond the structured hints.

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 compact sentences, front-loaded with the core action and its immediate result, then the follow-up obligation. Efficient, though the raw HTTP path 'POST generations?async=true' leaks implementation detail instead of describing intent.

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 not be explained, and the async/persistence workflow is covered. Still missing for an 8-parameter, paid, open-world mutation tool are the group=official vs reverse implications, the official_options precondition, and model-choice guidance.

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 63%, and the schema itself carries rich per-field documentation (size constraints, group semantics, model selection, official_options gating). The description adds no parameter-level meaning beyond the raw 'async=true' endpoint form, so it neither compensates for the coverage gap nor contradicts anything.

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 states a specific verb and resource ('提交收费异步绘图' – submit a paid asynchronous image generation) and pins down the immediate return value ('立即返回 task_id'). The 'async' qualifier implicitly separates it from the synchronous generate_image sibling, though no sibling is named explicitly.

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?

It tells the agent it must keep polling ('必须继续查询才能自动落盘'), which implies the get_image_task/wait_image_task siblings, and flags the operation as paid. However it never states when to pick this over generate_image, submit_image_edit, or submit_image_batch, leaving the selection decision to inference.

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?

Annotations already cover safety (idempotent=true, destructive=false, openWorld=true), and the description adds genuine context beyond them: bounded polling, that read-only retries count toward the wait budget, that timeout returns task_id/wait_timed_out while the cloud task continues, and that success writes to disk. It does not mention auth or rate-limit behavior, keeping it 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?

A single dense sentence that front-loads the core concept ('有界轮询') before timeout and re-query behavior. No filler, though the multi-clause packing makes it slightly harder to parse than it needs to be.

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 not be enumerated, and the annotations carry the safety profile. The description covers the main waiting/timeout behavior adequately, but for a 4-parameter tool with 25% schema coverage the undocumented polling parameters remain an incomplete picture.

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 only 25% (only output_dir is documented), so the description must compensate, and it largely does not. poll_interval and timeout_seconds have no descriptions anywhere, and the description only vaguely alludes to a 'wait time limit' and disk landing rather than mapping meaning onto those parameters.

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 states a specific operation — bounded polling of an image task ('有界轮询'), with the state transitions (NOT_START/IN_PROGRESS) that it waits on. It is clear what the tool does, but it never names or contrasts against the obvious sibling get_image_task, so an agent must infer the difference itself.

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: waiting continues while the task is queued or in progress, and '可稍后再次查询' hints at re-querying after a timeout. There is no explicit when-to-use-this vs use-get_image_task guidance, leaving the choice between polling and single-query siblings to inference.

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