Skip to main content
Glama
Wulnut

lark-agent

by Wulnut
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

bind_child_tasks

Assign multiple child issue IDs to a parent issue as subtasks via specified relation rules, enabling clear task hierarchy and organization.

Instructions

将多个工作项绑定为指定父工作项的“子任务”（通过关联关系规则实现）。

Args:
    parent_issue_id: 父工作项 ID（必填）。
    child_issue_ids: 子工作项 ID 列表（必填）。
    relation_name: 关联规则名称（可选）。当存在多条规则时建议必填。
    project: 项目标识符（可选）。可以是项目名称或 project_key；不传则使用默认项目。
    work_item_type: 工作项类型名称（可选）。
    user_key: (可选) 飞书用户标识符 (X-USER-KEY)。

Returns:
    JSON 字符串。

    成功时（success=true）data 格式：
    {
      "parent_issue_id": int,
      "child_issue_ids": [int, ...],
      "relation_name": str
    }

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectNo
user_keyNo
relation_nameNo
work_item_typeNo
child_issue_idsYes
parent_issue_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.2

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the burden and does add useful behavior: it specifies that success returns a JSON string with a defined data structure and that failures return plain-text errors handled by with_error_handling. However, it does not disclose side-effect behavior such as whether existing child bindings are replaced, whether the operation is idempotent, or what permissions are required.

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

Conciseness4/5

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

The purpose is front-loaded in one clear sentence, and the Args/Returns sections are organized and scannable. The internal reference to with_error_handling is minor noise, but overall every section earns its place.

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 output schema already covers the success return shape, and the description usefully adds the failure mode and parameter semantics. For a mutating operation with no annotations, however, the absence of when-to-use guidance and side-effect disclosure leaves the agent under-informed about consequences and alternatives.

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 explaining all six parameters, including defaults for project and user_key and a recommendation for relation_name. The only weak spot is work_item_type, which is described as a name but not given its purpose in the binding operation.

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

Purpose4/5

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

The opening sentence states a specific action (bind multiple work items) on a specific resource (parent work item's child tasks) via relation rules, which is clear and distinct from sibling operations like unbind_child_tasks. It does not explicitly name the sibling alternatives, so it stops one step short of full differentiation.

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

Usage Guidelines2/5

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

The description gives parameter-level advice, notably that relation_name should be provided when multiple rules exist, but it never tells the agent when to choose this tool over unbind_child_tasks or list_child_tasks. There is no stated condition, prerequisite, or exclusion, so usage context is largely absent.

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

Deploy Server

Other Tools