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

With no annotations, the description carries the full transparency burden. It implies a read-only status lookup, but says nothing about behavior for pending vs failed vs expired task_ids, whether results are returned only on completion, polling expectations, or authentication requirements. Only the return content ('进度与成片结果') is hinted at.

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 platform and purpose front-loaded, followed by the parenthetical detail. Nothing is redundant, though the parenthetical prefix enumeration makes it slightly heavier than strictly necessary.

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 one-parameter, no-output-schema tool, the description at least names what comes back (progress and final result) and which ID families are valid. It is still thin on the states a task can be in and what a failure response looks like, which an agent polling a status endpoint genuinely needs.

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% and there is one parameter, so the description must compensate. It does add real value by defining the task_id namespace (rm_ / ss_ / tf_ / img_ prefixes), which tells the agent what kind of identifier is valid. It still omits format details such as whether the prefix is included, but this meaningfully beats the empty schema.

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 ('查询异步任务...的进度与成片结果') and enumerates the concrete task families it covers via ID prefixes (rm_ / ss_ / tf_ / img_). That is far more specific than the bare name. It does not, however, distinguish itself from the similarly-purposed sibling kgc_job_status, so an agent cannot route between them on this text 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?

Usage is only implied: the prefix list tells the agent which task_ids this tool accepts, which is genuine context for 'when this applies'. But there is no explicit when-to-use, no exclusion, and no pointer to alternatives such as kgc_job_status or publish_status for other job types.

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