Skip to main content
Glama

查询 TAPD bug 列表

tapd_list_bugs
Read-only

Query TAPD bugs by owner, project, or filter by ID, status, priority, and more. Supports cross-project aggregation and custom fields.

Instructions

查询 TAPD bug 列表,默认查询当前登录用户负责的缺陷;传入 current_owner 可查询指定处理人名下的缺陷。传入 id 或 story_id 时不限处理人(story_id 返回该需求全部处理人名下的关联缺陷),可查到已转给他人的缺陷;显式传入 current_owner 时再按该处理人取交集。传入 workspace_id 时只查该项目;不传 workspace_id 时会聚合处理人参与的所有项目的缺陷(按 story_id 过滤时仍需具体项目)。支持按字段过滤:缺陷 ID、关联需求、标题、描述、状态、报告人、处理人、创建时间,以及优先级、严重程度、中文状态、标签、迭代、模块、版本/基线、发布计划、特性、缺陷类型/根源/解决方法/重现规律、各类人员(测试/开发/参与/抄送/修复/验证/审核/关闭人等)、环境(操作系统/平台)、测试方式/阶段/类型、排期/解决/关闭/修改/流转时间、自定义字段等,并可自定义排序(order)。返回的状态会附带项目工作流中文名(如「已解决(resolved)」)。【展示约定】向用户呈现结果时,请直接原样输出本工具返回的 Markdown 表格,完整保留「序号」「id」在内的所有列(其中「缺陷」列已是内嵌超链接的 Markdown 写法,请勿拆成裸 URL、改成纯文本或删除链接),不要裁剪列、改列名或将表格拆分重排;如需补充分类或小结,可在表格之外另起段落,但表格本身保持原样。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNo可选,抄送人 TAPD nick
deNo可选,开发人员 TAPD nick,支持模糊匹配
idNo缺陷 ID,TAPD 支持多 ID 查询。传入 id 时默认跳过处理人过滤(除非同时显式传入 current_owner),以便查到已转出的缺陷
osNo可选,操作系统
teNo可选,测试人员 TAPD nick,支持模糊匹配
dueNo可选,预计结束时间
pageNo页码,默认 1。聚合查询(不传 workspace_id)时按每个项目分别分页,并非跨项目全局分页
beginNo可选,预计开始时间
fixerNo可选,修复人 TAPD nick
labelNo可选,标签,TAPD 支持枚举查询
limitNo返回数量上限,默认 30,最大 200;聚合查询时为每个项目的上限
orderNo可选,排序规则,格式「字段名 asc|desc」(如 created desc),不传默认 modified desc。注意:聚合查询(不传 workspace_id)时各项目内按此排序取数,但跨项目合并后最终仍按修改时间倒序展示
titleNo缺陷标题,TAPD 支持模糊匹配
closedNo可选,关闭时间,TAPD 支持时间查询
closerNo可选,关闭人 TAPD nick
moduleNo可选,模块,TAPD 支持枚举查询
sourceNo可选,缺陷根源,TAPD 支持枚举查询
statusNo缺陷状态,TAPD 支持枚举查询和不等于查询
auditerNo可选,审核人 TAPD nick
bugtypeNo可选,缺陷类型
createdNo创建时间,TAPD 支持时间查询
featureNo可选,特性
deadlineNo可选,解决期限
estimateNo可选,预计解决时间
modifiedNo可选,最后修改时间,TAPD 支持时间查询
platformNo可选,软件平台
reporterNo报告人,TAPD 支持多用户查询
resolvedNo可选,解决时间,TAPD 支持时间查询
severityNo可选,严重程度,TAPD 支持枚举查询
story_idNo关联需求 ID,返回该需求的关联缺陷;默认不按当前登录用户过滤(与按 id 精确查询一致,可查到他人名下的关联缺陷),仅在显式传入 current_owner 时按该处理人取交集。与 id 参数同时使用时取交集;该过滤需要具体项目,必须同时传入 workspace_id
testmodeNo可选,测试方式
testtypeNo可选,测试类型
v_statusNo可选,状态,支持传入中文状态名(如「已解决」)
confirmerNo可选,验证人 TAPD nick
frequencyNo可选,重现规律,TAPD 支持枚举查询
testphaseNo可选,测试阶段
lastmodifyNo可选,最后修改人 TAPD nick
release_idNo可选,发布计划 ID
resolutionNo可选,解决方法,TAPD 支持枚举查询
descriptionNo缺陷详细描述,TAPD 支持模糊匹配
reject_timeNo可选,拒绝时间,TAPD 支持时间查询
verify_timeNo可选,验证时间,TAPD 支持时间查询
version_fixNo可选,合入版本
iteration_idNo可选,迭代 ID,TAPD 支持枚举查询
participatorNo可选,参与人,支持多人员查询
version_testNo可选,验证版本
workspace_idNoTAPD 项目 ID。传入则只查该项目;不传则聚合处理人参与的所有项目的缺陷。可先用 tapd_list_workspaces 查看会覆盖哪些项目
baseline_findNo可选,发现基线
baseline_joinNo可选,合入基线
baseline_testNo可选,验证基线
current_ownerNo单个处理人 TAPD nick,不传默认查询当前登录用户负责的缺陷;传入则查询指定处理人名下的缺陷,建议先用 tapd_search_users 确认 nick
custom_fieldsNo可选,自定义字段过滤透传。key 为 TAPD 字段名(custom_field_*、cus_* 或 custom_plan_field_*),原样提交;具体字段名通过 TAPD 自定义字段配置接口获取
version_closeNo可选,关闭版本
baseline_closeNo可选,关闭基线
priority_labelNo可选,优先级(推荐字段,兼容自定义优先级)
version_reportNo可选,发现版本,TAPD 支持枚举查询
in_progress_timeNo可选,接受处理时间,TAPD 支持时间查询
Behavior5/5

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

Read-only annotation is consistent. Description details aggregation across projects, pagination per project, order behavior, and status format beyond what annotations provide.

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

Conciseness3/5

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

Description is a single verbose paragraph. While front-loaded with purpose, it could be more structured (e.g., bullet points) to improve readability for an AI agent.

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?

For a tool with 57 parameters and no output schema, description covers major behaviors (defaults, aggregation, pagination, order, presentation rules). Lacks details on return structure beyond Markdown table mention.

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 covers 100% of parameters. Description adds contextual interaction details (e.g., id bypasses owner filter unless current_owner specified, story_id requires workspace_id), supplementing schema descriptions.

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?

Description clearly states it queries TAPD bug list, defaults to current user, and specifies how to filter by owner, id, story_id, workspace_id. However, it does not distinguish from sibling tapd_get_bugs, which may overlap in functionality.

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?

Provides explicit guidance on when to use parameters (e.g., current_owner, id, workspace_id) and default behavior. Lacks explicit exclusions or alternatives to sibling tools like tapd_get_bugs.

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