Skip to main content
Glama
Sign In
OpenProject CE MCP

OpenProject CE MCP

by jtauschl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_work_package_reactions

Read-onlyIdempotent

Retrieve emoji reactions on a work package's comments, returning one row per comment and reaction to show repeated reactions.

Instructions

List emoji reactions across a work package's comment activities.

One row per comment and reaction, without the activity id, so a reaction can repeat.

Input Schema

NameRequiredDescriptionDefault
selectNoFields to return; a requested unset field comes back as null. Allowed: count, emoji, reaction, users.
work_package_idYesWork package id (e.g. 952) or display id (e.g. "PROJ-51"), not the bare number 51.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.4
  2. Removedv0.4.0
  3. Changed1 schema field changedv0.3.7
    • addedInput schema / additionalProperties
      Added value: +false
  4. Addedv0.3.3
  5. Removedv0.3.0
  6. Changed1 schema field changedv0.2.3
    • changedOutput schema / (root)
      Previous value: -{
-  "$defs": {
-    "EmojiReactionSummary": {
-      "properties": {
-        "count": {
-          "title": "Count",
-          "type": "integer"
-        },
-        "emoji": {
-          "anyOf": [
-            {
-              "type": "string"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "title": "Emoji"
-        },
-        "reaction": {
-          "title": "Reaction",
-          "type": "string"
-        },
-        "users": {
-          "items": {
-            "type": "string"
-          },
-          "title": "Users",
-          "type": "array"
-        }
-      },
-      "required": [
-        "reaction",
-        "emoji",
-        "count",
-        "users"
-      ],
-      "title": "EmojiReactionSummary",
-      "type": "object"
-    }
-  },
-  "properties": {
-    "count": {
-      "title": "Count",
-      "type": "integer"
-    },
-    "results": {
-      "items": {
-        "$ref": "#/$defs/EmojiReactionSummary"
-      },
-      "title": "Results",
-      "type": "array"
-    }
-  },
-  "required": [
-    "count",
-    "results"
-  ],
-  "title": "EmojiReactionListResult",
-  "type": "object"
-}New value: +null
  7. First observedv0.2.2

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description adds real value beyond them by explaining the row shape ('one row per comment and reaction, without the activity id, so a reaction can repeat'), warning the agent not to treat repeated rows as duplicates. It does not mention ordering or pagination.

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?

Two short sentences, front-loaded with the action and followed by the one non-obvious output detail. No filler or repetition of the name.

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 two-parameter read tool with full annotations and full schema descriptions, the description covers the main ambiguity an agent would hit (duplicate-looking rows). Minor gaps remain on ordering and whether reactions span non-comment activities, but nothing blocks correct invocation.

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%, and the schema already explains work_package_id formats and the allowed select fields. The description adds nothing parameter-specific, so the baseline 3 applies.

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?

States a specific verb and resource: listing emoji reactions scoped to a work package's comment activities. An agent can tell it apart from mutation siblings like toggle_activity_emoji_reaction by the 'List' verb, though the description never names an alternative explicitly.

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?

Usage is only implied by the read-only framing; there is no statement of when to call this versus toggle_activity_emoji_reaction or get_work_package_activities. An agent must infer that this is the read path for reaction data.

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

Deploy Server

Other Tools