Skip to main content
Glama
Wulnut
by Wulnut

get_tasks

Retrieve work items from Feishu projects using filters for name keyword, status, priority, owner, or related item. Get complete lists or targeted results to support project tracking.

Instructions

获取项目中的工作项列表(支持全量获取或按条件过滤)。

这是通用的任务获取工具,具备以下特性:
1. 无过滤参数时,返回项目的全部工作项
2. 支持按任务名称关键词进行高效搜索(推荐)
3. 支持按状态、优先级、负责人进行灵活过滤
4. 支持按关联工作项 ID 或名称过滤(查找与指定工作项关联的项)
5. 如果项目不存在某个字段(如状态),会自动跳过该过滤条件
6. 支持指定工作项类型(如 "需求管理"、"Issue管理"、"项目管理" 等)

Args:
    project: 项目标识符(可选)。可以是:
            - 项目名称(如 "Project Management")
            - project_key(如 "project_xxx")
            如不指定,则使用环境变量 FEISHU_PROJECT_KEY 配置的默认项目。
    work_item_type: 工作项类型名称(可选),如 "需求管理"、"Issue管理"、"项目管理" 等。
                   如果不指定,默认使用 "问题管理" 类型。
    name_keyword: 任务名称关键词(可选,支持模糊搜索,推荐使用)。
                  例如:"SG06VA" 可以搜索所有包含该关键词的任务。
    status: 状态过滤(多个用逗号分隔),如 "待处理,进行中"(可选)。
    priority: 优先级过滤(多个用逗号分隔),如 "P0,P1"(可选)。
    owner: 负责人过滤(姓名或邮箱)(可选)。
    related_to: 关联工作项 ID 或名称(可选)。用于查找与指定工作项关联的其他工作项。
               - 如果是整数或数字字符串,直接作为工作项 ID 使用
               - 如果是非数字字符串,自动搜索该名称对应的工作项(精确匹配优先)
               例如:related_to="SG06VA1" 或 related_to=6288163810
    page_num: 页码,从 1 开始(默认 1)。
    page_size: 每页数量(默认 50,最大 100)。
    user_key: (可选) 飞书用户标识符 (X-USER-KEY),用于以特定用户身份进行操作。

Returns:
    JSON 格式的工作项列表,包含 id, name, status, priority, owner。
    失败时返回错误信息。

Examples:
    # 获取默认项目的全部工作项
    get_tasks()

    # 获取"需求管理"类型的工作项
    get_tasks(project="Project Management", work_item_type="需求管理")

    # 按名称关键词搜索(推荐,高效)
    get_tasks(name_keyword="SG06VA")

    # 获取指定优先级的任务
    get_tasks(priority="P0,P1")

    # 查找与指定工作项关联的工作项(通过名称)
    get_tasks(related_to="SG06VA1", work_item_type="Issue管理")

    # 查找与指定工作项关联的工作项(通过 ID)
    get_tasks(
        project="Project Management",
        work_item_type="需求管理",
        related_to=6181818812
    )

    # 指定项目并组合多个条件过滤
    get_tasks(
        project="Project Management",
        work_item_type="需求管理",
        name_keyword="SG06VA",
        status="进行中",
        priority="P0"
    )

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ownerNo
statusNo
projectNo
page_numNo
priorityNo
user_keyNo
page_sizeNo
related_toNo
name_keywordNo
work_item_typeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.2

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses default project resolution via FEISHU_PROJECT_KEY, default work_item_type, behavior when a field does not exist, related_to matching semantics, pagination limits, and the user_key impersonation option.

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 long but well-structured with a summary line, numbered behavioral features, Args section, Returns section, and clear Examples. Every section adds value; the examples demonstrate realistic combinations and parameter formats without redundancy.

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 an 11-parameter list-fetch tool with no annotations, the description is complete. It covers default values, filtering behavior, output shape, error behavior, and usage examples. An agent has enough context to select the tool and invoke it correctly without inspecting sibling schemas.

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?

The input schema provides only titles and defaults with no descriptions. The description compensates fully by explaining every parameter in detail, including types, defaults, accepted formats, and real examples. related_to and project receive especially rich clarification.

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: '获取项目中的工作项列表' (get work item list in a project). It clearly enumerates supported filtering modes and explicitly distinguishes this list-oriented tool from sibling tools like get_task_detail, create_task, and 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 provides clear usage context: default behavior with no filters, recommended name_keyword search, optional filtering by status/priority/owner, and pagination. It even notes that nonexistent fields are skipped. However, it does not explicitly state when to prefer a sibling tool such as get_task_detail for single-item retrieval.

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