Skip to main content
Glama

Edit work package comment

edit_work_package_comment
Idempotent

Rewrite a work-package comment to fix typos or extend a note. Replaces the entire comment text with new markdown content; no history of previous version is kept.

Instructions

Rewrite the text of an existing work-package comment.

Use this to fix a typo, correct a wrong statement, or extend a note you just posted. Returns the updated journal entry (activity id, author, markdown text, internal flag, timestamps) in the same shape list_work_package_comments returns.

Pitfalls. Only comment entries are editable: the journal also holds field-change entries ("Status changed from New to In progress"), which OpenProject records automatically and refuses to alter — this tool rejects those locally, before any write. Editing needs the edit-work-package-comments permission (or edit-own for your own comments); a 403 means the account may read the thread but not rewrite it. The edit replaces the text entirely and OpenProject keeps no API-visible history of the previous version, so do not use it to "undo" — post a correcting comment when the record matters. Editing does not notify anyone.

Cross-references: read the thread and get activity ids with list_work_package_comments; post a new comment with add_work_package_comment; change fields (status, assignee, dates) with update_work_package instead of describing them in prose.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commentYesThe replacement body in markdown. It replaces the whole comment — there is no append mode, so read the current text first if you mean to add to it. @-mentions need OpenProject's mention syntax; plain names notify nobody.
activity_idYesId of the journal entry to rewrite. It comes from list_work_package_comments (the 'id' of an entry with kind='comment') or from add_work_package_comment's result. It is an activity id, not a work package id.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoActivity id. Pass it back as list_work_package_comments(activity_id=...) to read a truncated comment in full.
kindYes'comment' when the entry carries comment text, 'field_change' otherwise.
authorNoUser who wrote the entry.
commentNoComment body as markdown (raw); html is dropped. Cut to max_comment_chars when 'truncated' is true.
detailsNoField changes recorded with this entry; always a list, empty for a comment-only entry.
versionNoJournal version number of this entry within the work package.
internalNoTrue for internal (project-member-only) comments; OpenProject >= 16.
truncatedNoTrue when the comment was cut to max_comment_chars.
created_atNoISO 8601 UTC timestamp.
updated_atNoISO 8601 UTC timestamp of the last edit.
work_packageNoWork package the entry belongs to.
comment_lengthNoCharacter length of the untruncated comment; set only when truncated.
Behavior5/5

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

Beyond annotations, the description discloses that only comment entries are editable, field-change entries are rejected locally before any write, editing requires specific permissions, the text is replaced entirely with no API-visible history, editing does not notify anyone, and the return shape matches list_work_package_comments. No contradictions with annotations.

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?

Though lengthy, every sentence earns its place: purpose, use cases, return shape, pitfalls, permissions, irreversibility, and cross-references. The description is front-loaded with the primary action and well-structured with paragraph breaks for readability.

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?

The description is exhaustive given the tool's complexity: covers prerequisites, error handling (403), non-comment journal entries, side effects (no notifications, no history), and explicitly names sibling tools. An output schema exists, so return values require no further explanation.

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 coverage is 100% with detailed descriptions for both parameters (comment, activity_id). The tool description adds little beyond the schema: 'replaces text entirely' and 'activity id' already appear in the schema. The baseline of 3 applies because structured data carries the semantic load.

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 'Rewrite the text of an existing work-package comment,' a specific verb+resource statement. It further clarifies use cases (fix a typo, correct a wrong statement, extend a note) and differentiates from add_work_package_comment and update_work_package via cross-references.

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?

Explicitly states when to use ('Use this to fix a typo...'), when not to use ('do not use it to "undo"'), and names specific alternatives (list_work_package_comments, add_work_package_comment, update_work_package). It also explains the permission requirements and 403 implication.

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/kar-thik/openproject-mcp'

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