Skip to main content
Glama
Wulnut
by Wulnut

get_task_transition_requirements

Retrieve mandatory fields and role owners needed before transitioning a work item to a target status. Ensures all required information is provided to avoid failed status changes.

Instructions

获取将指定工作项流转到目标状态前的必填信息要求。

该工具用于在执行状态流转前,先询问系统:从当前状态流转到 target_status 需要补全哪些字段。
常见场景包括:
- 流转到“已完成/已关闭”时需要填写“解决方案”“原因”“验证人”等字段
- 流转到某些阶段需要指定角色负责人(role owners)或填写额外信息

本工具仅负责:
1) project/work_item_type 参数解析(project_name 与 project_key 分支)
2) 委托 WorkflowProvider 解析状态名并调用 WorkflowAPI.get_transition_required_info
3) 返回统一的 JSON envelope(success/data),便于 LLM 稳定解析

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

Args:
    issue_id: 工作项 ID,必填。
    target_status: 目标状态名称(人类可读),必填。例如:"已完成"、"待处理"。
    project: 项目标识符(可选)。可以是项目名称或 project_key;不传则使用环境变量 FEISHU_PROJECT_KEY 指定的默认项目。
    work_item_type: 工作项类型名称(可选)。例如:"问题管理"、"Issue管理"。
    mode: 工作流查询模式(可选)。透传给后端接口,用于控制必填项返回策略。
    user_key: (可选) 飞书用户标识符 (X-USER-KEY),用于以特定用户身份进行操作。

Returns:
    JSON 字符串。

    成功时(success=true)data 格式至少包含:
    {
      "required_fields": [ ... ]
    }

    失败时返回纯文本错误信息(由 with_error_handling 统一处理),常见原因包括:
    - target_status 无法匹配(会提示“可选状态”)
    - 当前用户无权限查询该工作项的工作流信息
    - 网络/系统异常

Examples:
    # 查询将 Issue 123 流转到“已完成”前需要填哪些字段
    get_task_transition_requirements(issue_id=123, target_status="已完成")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo
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.7/5.0
Behavior5/5

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

没有 annotations,描述承担了完整的行为披露义务。它明确说明了成功时返回 JSON 字符串、失败时返回纯文本错误信息,并列出常见错误原因和内部委托流程,agent 能准确预判调用结果。

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?

按场景、职责、注意、Args、Returns、Examples 分段组织,信息密度高且前置了核心用途。但成功/失败返回格式在注意和 Returns 两处重复说明,略有冗余。

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?

在无 annotations、参数描述覆盖率为 0% 的情况下,描述覆盖了所有必要调用信息:参数、返回值格式、错误模式、默认行为和示例。配合存在的输出 schema,agent 已具备正确调用该工具的完整上下文。

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

Parameters5/5

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

Schema 描述覆盖率为 0%,描述完全弥补了参数语义空白。每个参数都给出了含义、可选性、默认值或作用,包括 project 的环境变量回退、mode 的透传语义和 user_key 的用户身份用途。

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?

描述以明确的动词+资源说明了工具用途:获取将工作项流转到目标状态前需要补全的必填字段。与兄弟工具 transition_task_status 等形成清晰区分,且通过场景示例让用途一目了然。

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?

描述清楚指出了使用时机(在执行状态流转前查询必填要求),并给出常见场景和工具职责边界。但没有显式命名兄弟工具或说明何时不应使用本工具,排除性指引略弱。

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