Skip to main content
Glama
Wulnut
by Wulnut

unbind_child_tasks

Remove all child-task bindings from a parent work item by deleting the specified relation. Provide the parent issue ID to clear its linked child tasks.

Instructions

解绑指定父工作项的子任务关系(按关联关系规则整体解绑)。

当前最小实现:
- 调用 RelationAPI.delete 删除父工作项在该规则下的关联关系(服务端语义通常为“清空该规则下的绑定”)。

Args:
    parent_issue_id: 父工作项 ID(必填)。
    relation_name: 关联规则名称(可选)。
    project: 项目标识符(可选)。
    work_item_type: 工作项类型名称(可选)。
    user_key: (可选) 飞书用户标识符 (X-USER-KEY)。

Returns:
    JSON 字符串。

    成功时(success=true)data 格式:
    {
      "parent_issue_id": int,
      "relation_name": str
    }

失败时返回纯文本错误信息(由 with_error_handling 统一处理)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectNo
user_keyNo
relation_nameNo
work_item_typeNo
parent_issue_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.2

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the burden, and it does well by disclosing that the implementation calls RelationAPI.delete and that the server semantics usually mean 'clear all bindings under this rule.' It also states that failures return plain-text errors via with_error_handling. However, it does not clarify behavior when relation_name is omitted or whether the operation is reversible, so it is not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with an implementation note, an Args section, and a Returns section. The purpose is front-loaded, and every sentence provides useful information without filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, parameters, return format, and failure behavior, and an output schema exists, so return values do not need much explanation. The main gap is that relation_name is optional, yet the description repeatedly refers to '该规则' without stating what happens when relation_name is not provided or how the rule is otherwise determined. This is a meaningful ambiguity for a 5-parameter tool with no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates by enumerating all five parameters with roles and required/optional status, such as parent_issue_id being required and user_key mapping to X-USER-KEY. It adds meaning beyond the schema's titles and defaults, but it does not explain how the optional parameters combine to identify the specific rule or what happens when relation_name is absent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: '解绑指定父工作项的子任务关系' (unbind child-task relationships of a specified parent work item). It also clarifies the scope as '按关联关系规则整体解绑' (unbind as a whole per relation rule), which distinguishes it from per-child unbinding and from sibling tools like bind_child_tasks and list_child_tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the tool name and purpose: use this to remove child-task relation bindings for a parent work item. However, the description does not explicitly state when to use it versus alternatives, when not to use it, or any prerequisites such as whether the relation must already exist.

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