Skip to main content
Glama

查询 TAPD 需求列表

tapd_list_stories
Read-only

Search TAPD requirements by owner, status, ID, workspace, and custom fields. Returns markdown table with workflow status names.

Instructions

查询 TAPD 需求列表,默认查询当前登录用户负责的需求;传入 owner 可查询指定处理人名下的需求。传入 id 精确查询时不限处理人,可查到已转给他人的需求。传入 workspace_id 时只查该项目;不传 workspace_id 时会聚合处理人参与的所有项目的需求。支持按字段过滤:需求 ID、名称、描述、状态、创建人、处理人、创建时间,以及优先级、标签、版本、模块、迭代、分类、排期/修改/完成时间、父子需求、特性、技术风险、需求类别、发布计划、规模、测试重点、抄送/开发人、来源/类型、工时、自定义字段等,并可自定义排序(order)。返回的状态会附带项目工作流中文名(如「已实现(resolved)」)。【展示约定】向用户呈现结果时,请直接原样输出本工具返回的 Markdown 表格,完整保留「序号」「id」在内的所有列(其中「需求」列已是内嵌超链接的 Markdown 写法,请勿拆成裸 URL、改成纯文本或删除链接),不要裁剪列、改列名或将表格拆分重排;如需补充分类或小结,可在表格之外另起段落,但表格本身保持原样。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNo可选,抄送人 TAPD nick
idNo需求 ID,TAPD 支持多 ID 查询。传入 id 时默认跳过处理人过滤(除非同时显式传入 owner),以便查到已转出的需求
dueNo可选,预计结束时间,TAPD 支持时间查询
nameNo需求名称,TAPD 支持模糊匹配
pageNo页码,默认 1。聚合查询(不传 workspace_id)时按每个项目分别分页,并非跨项目全局分页
sizeNo可选,规模
typeNo可选,类型
beginNo可选,预计开始时间,TAPD 支持时间查询
labelNo可选,标签,TAPD 支持枚举查询
limitNo返回数量上限,默认 30,最大 200;聚合查询时为每个项目的上限
orderNo可选,排序规则,格式「字段名 asc|desc」(如 created desc),不传默认 modified desc。注意:聚合查询(不传 workspace_id)时各项目内按此排序取数,但跨项目合并后最终仍按修改时间倒序展示
ownerNo单个处理人 TAPD nick,不传默认查询当前登录用户负责的需求;传入则查询指定处理人名下的需求,建议先用 tapd_search_users 确认 nick
effortNo可选,预估工时
exceedNo可选,超出工时
moduleNo可选,模块
remainNo可选,剩余工时
sourceNo可选,来源
statusNo需求状态,TAPD 支持枚举查询和不等于查询
createdNo创建时间,TAPD 支持时间查询
creatorNo创建人,TAPD 支持多用户查询
featureNo可选,特性
versionNo可选,版本
modifiedNo可选,最后修改时间,TAPD 支持时间查询
v_statusNo可选,状态,支持传入中文状态名(如「已实现」)
completedNo可选,完成时间,TAPD 支持时间查询
developerNo可选,开发人员 TAPD nick
parent_idNo可选,父需求 ID,查询其直接子需求
tech_riskNo可选,技术风险
release_idNo可选,发布计划 ID
test_focusNo可选,测试重点
ancestor_idNo可选,祖先需求 ID,查询其下所有层级子需求
category_idNo可选,需求分类 ID,TAPD 支持枚举查询
children_idNo可选,子需求 ID;查询无子需求的需求时传「|」
descriptionNo需求详细描述,TAPD 支持模糊匹配
iteration_idNo可选,迭代 ID,TAPD 支持枚举/不等于查询
workspace_idNoTAPD 项目 ID。传入则只查该项目;不传则聚合处理人参与的所有项目的需求。可先用 tapd_list_workspaces 查看会覆盖哪些项目
custom_fieldsNo可选,自定义字段过滤透传。key 为 TAPD 字段名(custom_field_*、cus_* 或 custom_plan_field_*),原样提交;具体字段名通过 TAPD 自定义字段配置接口获取
priority_labelNo可选,优先级(推荐字段,兼容自定义优先级),TAPD 支持枚举查询
effort_completedNo可选,完成工时
workitem_type_idNo可选,需求类别 ID
include_leaf_storiesNo可选,是否包含子需求,默认否
include_sub_categoryNo可选,是否包含子分类,默认否
include_sub_iterationNo可选,是否包含子迭代,默认否
Behavior4/5

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

Annotations only provide readOnlyHint=true, which matches the query-only behavior. The description goes further by disclosing aggregation pagination (per-project pages) and final sort order after merge, beyond what annotations convey.

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 lengthy but well-structured: core behavior first, then filtering, then display convention. It could be more concise, but the detail is warranted given the tool's complexity. Front-loaded with key info.

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

Completeness4/5

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

Given 43 parameters and no output schema, the description covers essential invocation details: return format (Markdown table with all columns), pagination, sorting, and aggregation behavior. Minor gaps in exact column list, but sufficient for selection and invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds some extra context (e.g., id bypasses owner filter, aggregation pagination) but does not significantly enhance parameter understanding beyond the schema's descriptions.

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 clearly states the tool queries TAPD stories, with default behavior (current user's stories) and options to filter by owner, workspace_id, and many fields. It distinguishes from sibling tools (e.g., bugs) by focusing on stories.

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

Usage Guidelines5/5

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

Provides explicit guidance on when to use: default owner, workspace_id scoping, aggregation vs single project, and suggests using tapd_search_users and tapd_list_workspaces for preparation. Also explains pagination and sorting differences.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sun-jingtao/tapd-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server