Skip to main content
Glama

List work package comments

list_work_package_comments
Read-onlyIdempotent

Get the full comment thread and change history for any work package, including author, text, and field updates (e.g., status changes).

Instructions

Read the comment thread and change history of a work package.

Use this whenever the question is "what did people say about this ticket" or "what changed on it": it returns the full activity journal — comment entries (author, markdown text, internal flag, timestamps) and field-change entries whose details are parsed into {field, from, to} (for example {"field": "Status", "from": "New", "to": "In progress"}).

Returns the standard list envelope: items plus pagination{total,page,page_size,has_more} and notes.

Pitfalls. OpenProject's activities endpoint is unpaginated — this tool fetches the entire journal on every call and pages it here, so page/page_size cost the same upstream but keep the reply small. Entries are ordered oldest first, so ask for the last page to see the latest discussion. Comment text is cut at max_comment_chars and marked truncated: true; pass that entry's id back as activity_id to read it in full.

Cross-references: post a comment with add_work_package_comment; the work package itself (description, custom fields, watchers) comes from get_work_package; files referenced in a comment are listed by list_attachments.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesWork package id. Get it from search_work_packages, list_work_packages or get_work_package — never guess it.
pageNo1-based page number over the journal. Entries are oldest first, so the newest comments are on the LAST page.
page_sizeNoJournal entries per page, 1-100. Keep it small: comments are long.
activity_idNoRead exactly one journal entry, uncapped, instead of a page. The id comes from a previous call to this tool. Must belong to work package `id`.
max_comment_charsNoPer-comment character cap, 50-50000. A cut comment comes back with truncated=true and comment_length; re-read it in full via activity_id.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sumsNoPresent only when show_sums was requested.
itemsNoThe page of results.
notesNoDegradation markers: capped aggregations, unavailable modules, …
groupsNoPresent only when group_by was requested.
paginationYesTotal/page/page_size/has_more.
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds significant behavior beyond that: the upstream endpoint is unpaginated, the tool fetches the full journal and pages locally, entries are oldest-first, and comments may be truncated with a recovery path via activity_id. No contradiction 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 long, the description is tightly structured with labeled 'Pitfalls' and 'Cross-references' sections. Every sentence adds operational value, and the main purpose is front-loaded. There is no redundancy or filler.

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 complete for the tool's complexity: it explains the return envelope (items, pagination, notes), unusual upstream behavior, truncation, and links to related tools. With an output schema present, no further explanation of return values is needed.

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?

Input schema covers 100% of parameters with descriptions, giving a baseline of 3. The description enriches this by explaining the practical implications: page/page_size meaning in the context of oldest-first ordering, cost trade-offs, truncation behavior tied to max_comment_chars, and the activity_id round-trip for reading full entries. This goes well beyond the 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: 'Read the comment thread and change history of a work package.' It clearly distinguishes this from siblings like add_work_package_comment or get_work_package by stating exactly what is returned (comment entries, parsed field-change entries). The scope is unambiguous.

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?

Explicit usage guidance is provided: 'Use this whenever the question is "what did people say about this ticket" or "what changed on it"'. It also names alternatives for related actions (add_work_package_comment, get_work_package, list_attachments), helping the agent choose between tools.

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