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

With no annotations, the description carries the full burden and does so: stage text is explicitly non-final, completed runs return summary, artifact list, billing settlement status and actually deducted credits, and reservation is clarified as not equal to an actual charge. It also discloses the terminal failure shape — saved and validated summary/artifacts retained with failed status and credits_insufficient reason — so the agent knows what a stopped run looks like and how to present it.

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?

It is front-loaded: purpose and returned fields first, polling protocol second, completion/billing/failure semantics last. Every clause carries information, though the semicolon-chained sentences pack billing policy, return payloads and agent conduct directives into very dense runs, making it harder to scan than a bulleted contract would 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?

With no output schema and no annotations, the description supplies what an agent needs: the return payload at each state (in-progress text, completion summary/artifacts/billing, failure with credits_insufficient) and the polling contract. The remaining gap is provenance of task_id and any statement of idempotency/side effects, which matter for a tool the agent may call in a loop.

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 67%: after_cursor and wait_seconds are already documented in the schema, and the description mostly restates them (the next_cursor→after_cursor handoff and the ~20s wait) rather than adding new syntax or format detail. The required task_id has no description in either the schema or the description text, so the single most important parameter's origin and format remain unexplained.

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 specific verb and resource: '读取普通科研任务的真实进展、已完成处理步骤数和可公开的阶段正文', telling the agent exactly what is fetched (progress, completed step count, publicly visible stage text). It implicitly separates itself from start_research_review and get_research_artifact by framing this as a read/poll of task state, but it never names a sibling or clarifies the scope of '普通' (ordinary discipline) versus other task types.

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 gives an explicit operational loop: after showing new stage content, pass next_cursor back as after_cursor and wait up to the 20-second default to avoid empty polls. It also prescribes behavior after a credit-exhaustion stop (show completed work and remaining items, don't claim full completion, don't auto-rebuild the billed task). What's missing is routing guidance — it never says when to call this versus start_research_review, get_research_artifact, or get_account_status.

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