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

Annotations already declare the mutating, non-idempotent, non-destructive, open-world profile, but the description adds real context: a login requirement (需登录), that history is recorded, and semantic constraints on the succeeded status for manual vs auto items. It does not detail reversibility or return format beyond 'ordered stage items'.

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 login prerequisite and is dense with no filler; each clause carries operational meaning. The bracketed labels (【需登录】【组合链】) aid scanning but make it slightly cluttered.

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 non-idempotent mutation with no output schema, the description covers prerequisites, the call chain, status semantics, and retry guidance. It leaves undefined what stageGoals contains and how failures other than timeout surface.

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 33% (only taskKey documented), so the description must compensate and partly does: it explains taskKey comes from get_my_positioning and clarifies status semantics (manual succeeded = done, auto follows platform records). The note parameter and the other enum values (started/learned/blocked/paused) remain undefined.

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: record (记) the outcome/note/history of a positioning task according to the user's real progress, and returns ordered stage items. It is clearly distinguishable from the read-only sibling get_my_positioning, which it names as the source of taskKey and the full-list reader.

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?

Explicitly prescribes the workflow: get_my_positioning to obtain taskKey → report truthfully → continue per stageGoals; use get_my_positioning for the full list. It also gives when-not rules (generating a document is not registration/deal/funding completion and cannot auto-report succeeded) and an operational rule (on timeout check status first, do not blindly retry).

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