task_receive

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

With no annotations provided, the description carries the full burden and does well: it discloses that the write is bound to the currently logged-in account, that the action is irreversible ('领取后不能撤销'), and that invalid statuses are rejected rather than partially applied. It does not cover concurrency or error payloads, nor whether instance_id/project_path affect the outcome.

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 dense sentences, each earning its place: what it does, the precondition and irreversibility, then the return value and next step. The irreversible-write warning is front-loaded rather than buried.

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?

Covers the operation, its irreversibility, the gating status, return fields and the required follow-up call — everything an agent needs to sequence it correctly. The only gap is that the role of instance_id/project_path is left entirely to the schema, though that schema is fully described.

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%, so task_id, instance_id and project_path are already documented, including the tasks_list source and the instance_id/project_path mutual exclusivity. The description adds no parameter-level detail beyond what the schema provides, so the 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 and resource ('领取一个征集任务' / claim a solicitation task) and immediately scopes it against the UI equivalent ('与活动中心的「领取」按钮相同'). It also distinguishes itself from the sibling task_bind by describing the sequence in which binding becomes possible only after receiving.

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 a hard precondition — only tasks in WAIT_RECEIVE status can be claimed and others are rejected outright — and names the follow-up step (re-run tasks_list, then task_bind). It does not explicitly say which sibling to use if the task is in another status, so an agent must infer the alternative, keeping this below a 5.

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