Skip to main content
Glama
Wulnut
by Wulnut

update_task_comment

Update the text of an existing comment on a work item by providing the issue ID, comment ID, and new plain-text content. Enables correcting or revising project comments without recreating them.

Instructions

更新指定评论内容(纯文本)。

Args:
    issue_id: 工作项 ID。
    comment_id: 评论 ID。
    content: 新的评论内容(纯文本)。
    project: 项目标识符(可选)。可以是项目名称或 project_key;不传则使用环境变量 FEISHU_PROJECT_KEY 指定的默认项目。
    work_item_type: 工作项类型名称(可选)。不传则使用默认类型。
    user_key: (可选) 飞书用户标识符 (X-USER-KEY)。

Returns:
    JSON 字符串。

    成功时(success=true)data 格式:
    {
      "issue_id": int,
      "comment_id": str
    }

    失败时返回纯文本错误信息(由 with_error_handling 统一处理),常见原因包括:
    - comment_id 不存在
    - 当前用户无权限编辑该评论
    - 评论内容为空

Examples:
    update_task_comment(issue_id=123, comment_id="c1", content="补充:已完成回归测试")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contentYes
projectNo
issue_idYes
user_keyNo
comment_idYes
work_item_typeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.2

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden; it does so well by specifying the success return format, the failure format (plain text via with_error_handling), and common error causes including permission and missing-comment cases. It also clarifies that content is pure text and how optional defaults are resolved.

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 well organized with Args, Returns, and Examples sections. Every sentence adds useful information, and the primary purpose is stated first. The example is concrete and demonstrates realistic usage.

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 six-parameter mutation tool, the description covers parameter semantics, return behavior, error cases, and an example. It is nearly complete; the only minor gap is explicit guidance on prerequisite or alternative tool selection, but that is not critical for invoking this tool correctly.

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 has 0% description coverage, but the description fully compensates by documenting every parameter: issue_id, comment_id, content, project, work_item_type, and user_key. It explains defaults, environment variable fallback, and optionality, providing meaning well beyond the bare schema.

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 opens with a specific verb+resource: '更新指定评论内容' (update specified comment content). It is clearly distinguished from sibling comment tools like add_task_comment and delete_task_comment by targeting an existing comment_id.

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

Usage Guidelines3/5

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

The usage is implied through the description: agents should use this when they need to modify an existing comment's content. However, there is no explicit guidance about when not to use it or when to prefer siblings such as add_task_comment or delete_task_comment.

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