Update task details by specifying only the fields to change. Pass a new tag_ids list to replace existing tags.
更新任务信息。只需传入要修改的字段。tag_ids 传入新列表会覆盖原有标签。
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 任务ID（必填） | |
| title | No | 新标题 | |
| tag_ids | No | 新的标签ID列表（覆盖） | |
| end_time | No | 新结束时间 | |
| project_id | No | 新所属项目ID | |
| start_time | No | 新开始时间 | |
| description | No | 新描述 |
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 bears the behavioral burden. It discloses the partial-update behavior and the important destructive-ish nuance that tag_ids replaces the original tag list entirely ('覆盖原有标签'). It does not mention response format or auth, but the core side effects are clearly stated.
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 short sentences, each earning its place: the operation, the update semantics, and the tag-overwrite caveat. It is front-loaded with the core purpose and contains no filler or redundant schema repetition.
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 moderate 7-parameter tool with one required id and fully commented schema, the description plus schema supplies enough to invoke correctly: required id, updatable fields, partial-update semantics, and the tag overwrite behavior. It could be more complete with a note about return values or how status updates should route to task_change_status, but the core invocation contract is present.
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 100%, so the schema already documents every parameter, giving the baseline 3. The description adds the general partial-update rule but largely restates what the schema already says for tag_ids ('覆盖'), without adding new syntax, formatting, or edge-case detail.
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 '更新任务信息', naming the resource and the update operation, and immediately clarifies the partial-update semantic with '只需传入要修改的字段'. The tag_ids overwrite caveat further differentiates this from task_add, task_delete, and even task_change_status by describing the field-level behavior.
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 clear invocation guidance ('只需传入要修改的字段'), telling the agent to send only changed fields, which implies skipped fields remain unchanged. However, it never explicitly says when to prefer task_update over sibling tools like task_change_status, and it provides no exclusions or alternative-routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.