Skip to main content
Glama
Wulnut
by Wulnut

transition_task_status

Move a work item to a specified target status in Feishu/Lark projects. Resolves human-readable status names into workflow transitions and submits required fields.

Instructions

将指定工作项流转到目标状态。

该工具用于执行飞书项目工作项的状态流转(Workflow Transition)。
它会根据 target_status(人类可读的状态名称)自动解析出对应的 state_key / transition_id,
并调用后端的 workflow state_change 接口完成流转。

使用建议:
- 在调用本工具前,建议先调用 get_task_transition_requirements 获取必填字段要求。
- fields 参数当前仅支持 list[dict] 透传(最小实现),用于满足流转前的必填字段。
  例如:[{"field_key": "field_x", "field_value": "y"}]。

注意:
- 成功时返回 JSON 字符串(success=true)。
- 失败时返回纯文本错误信息(由 with_error_handling 统一处理),不会返回 JSON。

Args:
    issue_id: 工作项 ID,必填。
    target_status: 目标状态名称(人类可读),必填。
    fields: 流转时需要提交的字段列表(可选)。元素为 dict,直接透传给后端。
    project: 项目标识符(可选)。可以是项目名称或 project_key;不传则使用环境变量默认项目。
    work_item_type: 工作项类型名称(可选)。
    mode: 流转模式(可选)。当前仅透传给 Provider,预留未来扩展。
    user_key: (可选) 飞书用户标识符 (X-USER-KEY)。

Returns:
    JSON 字符串。

    成功时(success=true)data 格式至少包含:
    {
      "issue_id": int,
      "target_status": str
    }

    失败时返回纯文本错误信息(由 with_error_handling 统一处理),常见原因包括:
    - target_status 无法匹配(会提示“可选状态”)
    - 流转失败(后端返回权限/参数错误等)

Examples:
    # 直接流转(无额外字段)
    transition_task_status(issue_id=123, target_status="已完成")

    # 带必填字段流转
    transition_task_status(
        issue_id=123,
        target_status="已完成",
        fields=[{"field_key": "field_resolution", "field_value": "已修复"}],
    )

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo
fieldsNo
projectNo
issue_idYes
user_keyNo
target_statusYes
work_item_typeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.2

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full disclosure burden, and it meets it thoroughly. It states success returns a JSON string with success=true, failure returns plain text via with_error_handling, the automatic resolution of state_key/transition_id, the default project behavior, and common error causes such as unmatchable target_status.

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 description is long but tightly organized into summary, usage suggestions, notes, Args, Returns, and Examples so an agent can scan efficiently. Some repetition exists between the Notes section and Returns section regarding failure returning plain text, but every sentence otherwise contributes meaningful call-related detail.

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

Completeness5/5

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

For a 7-parameter tool with no annotations and 0% schema description coverage, the description is essentially complete: it documents all parameters, return format, failure modes, pre-call requirements, and provides two examples. An agent has enough information to invoke this tool correctly and interpret its result.

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%, so the description must compensate, and it largely does. Every parameter is listed with a concise explanation: issue_id and target_status required, fields as list[dict] passthrough, project defaults to environment variable, mode reserved, user_key for Feishu identity. The included examples add useful concreteness for fields formatting, though mode and work_item_type remain somewhat underspecified.

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 opens with a specific verb and resource: '将指定工作项流转到目标状态' (transition the specified work item to a target state). It goes beyond a generic label by explaining that it resolves target_status into state_key/transition_id and invokes the backend workflow state_change endpoint, which clearly distinguishes it from content-update tools like update_task.

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

Usage Guidelines4/5

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

The description explicitly recommends calling get_task_transition_requirements before this tool, which is strong usage guidance for preparation. It also clarifies that fields is currently only a minimal list[dict] passthrough. It does not explicitly state when not to use this tool versus alternatives, but no sibling offers a workflow transition, so the main prerequisite guidance is sufficient.

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