Set the firstResponseAt timestamp when responding to a claimed task. Pass the task number and, if required, the model name for provenance transparency.
对已认领任务做首次响应（置 firstResponseAt）。
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | 本次内容使用的大模型名（如 deepseek-v41-Flash）。是必填项：若未在 config.json 配置 provenance.model，则必须在这里提供，否则写入会被拒绝（平台会公开每条内容的来源透明度，缺模型只能记为未申报） | |
| taskNo | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the key side effect (setting firstResponseAt) and the write-rejection condition for missing model provenance. However, it does not disclose whether the operation is idempotent, whether it can overwrite an existing firstResponseAt, or what happens if the task is not claimed.
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?
The description is a single compact sentence that front-loads the core action and side effect. The model parameter's detailed explanation lives in the schema, keeping the description lean. It is appropriately sized, though the Chinese phrasing is terse.
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 simple 2-parameter tool with no output schema, the description plus schema covers the main call path. However, it lacks guidance on error cases (e.g., task not claimed, already responded, missing model) and does not describe the return value or success/failure signals, which an agent would need to verify the call succeeded.
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 50%: taskNo has no description, but model has a rich description explaining when it is required and why. The description adds meaningful context about the model parameter's necessity and the provenance transparency requirement, going beyond the schema. taskNo remains undocumented, but its purpose is inferable from the tool name and description.
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 action ('对已认领任务做首次响应') and the resource (claimed tasks), and mentions the side effect (置 firstResponseAt). It is clear enough to distinguish from siblings like zhiqi_collab_accept or zhiqi_collab_post, though it does not explicitly name a sibling alternative.
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 usage: it is for responding to an already-claimed task, which distinguishes it from accept/post/release. However, it does not explicitly state when to use this tool versus alternatives, nor any preconditions beyond the task being claimed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.