Skip to main content
Glama

更新 TAPD bug

tapd_writeback

Update TAPD bugs with comments, status, title, description, assignees, custom fields, and more. Supports partial success reporting.

Instructions

对 TAPD bug 执行一个或多个已确认操作:回填评论、更新标题、更新描述正文、更新状态、更新处理人,以及更新优先级、严重程度、模块、版本、迭代、排期、各类人员、工时、标签等标准字段和自定义字段。各功能相互独立且可自由组合,至少提供 comment、title、description、target_status、target_owners、标准字段或 custom_fields 之一。注意:各动作分多次请求提交、非事务,可能出现部分成功(结果会逐项标明成功/失败)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNo可选,抄送人。与处理人同为 TAPD 用户 nick,多个以分号分隔(如 a;b;)
deNo可选,开发人员 TAPD nick
osNo可选,操作系统
teNo可选,测试人员 TAPD nick
dueNo可选,预计结束日期(YYYY-MM-DD)
sizeNo可选,规模
beginNo可选,预计开始日期(YYYY-MM-DD)
fixerNo可选,修复人 TAPD nick
labelNo可选,标签,不存在时自动创建,多个以英文竖线(|)分隔
titleNo可选,更新缺陷标题为该值
bug_idYesTAPD bug ID
closerNo可选,关闭人 TAPD nick
effortNo可选,预估工时
moduleNo可选,模块
sourceNo可选,缺陷根源
auditerNo可选,审核人 TAPD nick
bugtypeNo可选,缺陷类型
commentNo可选,回填到 TAPD 的评论内容
featureNo可选,特性
deadlineNo可选,解决期限(YYYY-MM-DD)
estimateNo可选,预计解决时间
platformNo可选,软件平台
severityNo可选,严重程度
testmodeNo可选,测试方式
testtypeNo可选,测试类型
confirmedYes必须为 true,表示用户已明确确认本次评论、标题、描述、字段、状态变更和处理人变更
confirmerNo可选,验证人 TAPD nick
frequencyNo可选,重现规律
testphaseNo可选,测试阶段
release_idNo可选,发布计划 ID
resolutionNo可选,解决方法
descriptionNo可选,更新缺陷描述正文(支持 HTML 富文本)。注意:该字段会整体覆盖原描述,应先获取原描述并在其基础上修改后传入完整正文
originphaseNo可选,发现阶段
sourcephaseNo可选,引入阶段
version_fixNo可选,合入版本
iteration_idNo可选,迭代 ID
participatorNo可选,参与人。与处理人同为 TAPD 用户 nick,多个以分号分隔(如 a;b;)
version_testNo可选,验证版本
workspace_idYesTAPD 项目 ID(必填)。可先用 tapd_list_bugs / tapd_list_stories 跨项目查询,或 tapd_list_workspaces 获取目标项目 ID
baseline_findNo可选,发现基线
baseline_joinNo可选,合入基线
baseline_testNo可选,验证基线
custom_fieldsNo可选,自定义字段透传。key 为 TAPD 字段名(custom_field_*、cus_* 或 custom_plan_field_*),原样提交;具体字段名通过 TAPD 自定义字段配置接口获取
target_ownersNo可选,将 bug 处理人更新为指定 TAPD 用户 nick 列表;应先调用 tapd_search_users 确认
target_statusNo可选,将 bug 状态更新为 TAPD 工作流中的状态值,如 resolved;必须使用当前项目实际支持的状态枚举。写入前会校验是否为项目工作流合法状态,非法状态将被拒绝并返回可选状态清单
version_closeNo可选,关闭版本
baseline_closeNo可选,关闭基线
priority_labelNo可选,优先级(对应 TAPD priority_label,兼容自定义优先级)
version_reportNo可选,发现版本
comment_root_idNo可选,评论的根评论 ID。传入时本条评论挂到该评论树下;需同时提供 comment
comment_reply_idNo可选,被回复的评论 ID,表示本条评论是对它的回复;需同时提供 comment
owner_update_modeNo可选,处理人更新方式。用户说“添加、加上、补上、也给”等追加语义时传 append;用户说“改为、替换为、转给、只保留”等替换语义时传 replace;不传默认 append
Behavior4/5

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

Discloses write operation, non-transactional multi-request behavior, partial success, and field-specific overwrite behavior (description field). With no annotations, description carries full burden and provides adequate behavioral context, though could mention more about permissions or rate limits.

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?

Description is concise and front-loaded with main purpose. Lists operations, then conditions, then warning in a clear structure. No wasted sentences, but could be slightly more efficient.

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 high complexity (52 params, 3 required) and no output schema, description covers what the tool does, constraints, and important behaviors (partial success, field overwrite, status validation). Could mention return format or error handling more, but adequate.

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 descriptions cover 100% of 52 parameters, so baseline is 3. Description adds high-level grouping and the constraint 'at least one of...' but does not significantly enhance meaning beyond the schema's parameter 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?

Description clearly states it updates TAPD bugs with multiple operations (comment, title, description, status, owners, fields). Verb '更新' and resource 'TAPD bug' are specific, distinguishing from sibling tools like tapd_create_bug (creation) and tapd_list_bugs (listing).

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?

Specifies required minimum inputs (at least one of comment, title, etc.) and notes non-transactionality with partial success. Provides context on when to use (updating a bug) but lacks explicit when-not-to-use or alternative tool references beyond implied sibling differentiation.

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