OpenProject CE MCP Server

Overview Schema Source Related Servers Discussions Admin

Remove work package watcher

remove_work_package_watcher

Idempotent

Unsubscribe a user from a work package's notifications to stop sending updates to someone who no longer needs them. Requires a work package ID and user ID.

Instructions

Unsubscribe a user from a work package's notifications.

Use this to stop notifying someone who no longer needs the updates. Returns the user, the watch state after the call (always not watching) and a confirmation message.

Pitfalls. OpenProject answers the same 204 whether or not the user was watching, so changed comes back null — do not report "removed" as proof that they were subscribed. Removing another user needs the delete-work-package-watchers permission; removing yourself only needs view access. A 404 means the user id is unknown (or the work package is), not that they were not watching. This does not unassign anyone and does not remove them from the project.

Cross-references: get_work_package(include=['watchers']) shows who watches today; add_work_package_watcher is the reverse.

Input Schema

Name	Required	Description	Default
`user_id`	Yes	Numeric id of the watcher to remove. get_work_package(include=['watchers']) lists the current watchers with their ids. The string 'me' is not accepted here.
`work_package_id`	Yes	Work package to unsubscribe the user from. Ids come from search_work_packages, list_work_packages or get_work_package.

Output Schema

Name	Required	Description	Default
`user`	No
`changed`	No
`message`	Yes
`watching`	Yes
`work_package_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.4.0Oct 24, 2026

removedOutput schema / description

Removed value: -"Outcome of adding or removing one watcher."

removedOutput schema / properties / changed / anyOf

Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]

removedOutput schema / properties / changed / default
```
Removed value: -null
```

removedOutput schema / properties / changed / description

Removed value: -"True when this call actually changed the watcher list, false when the user was already watching. Null when OpenProject does not report it — removals answer 204 whether or not the user was watching."

addedOutput schema / properties / changed / type
```
Added value: +[
+  "boolean",
+  "null"
+]
```
removedOutput schema / properties / message / description
```
Removed value: -"Human-readable confirmation."
```

changedOutput schema / properties / user / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "description": "A reference to another resource. Canonical output shape.",
-    "properties": {
-      "id": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Resource id."
-      },
-      "name": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Human-readable name."
-      }
-    },
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "type": [
+          "integer",
+          "string",
+          "null"
+        ]
+      },
+      "name": {
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / user / default
```
Removed value: -null
```

removedOutput schema / properties / user / description

Removed value: -"The watcher. 'id' is the user id; 'name' is filled in only when OpenProject returned the user resource (it does on add, not on remove)."

removedOutput schema / properties / watching / description

Removed value: -"Watch state after the call: true after adding, false after removing."

removedOutput schema / properties / work_package_id / description

Removed value: -"Work package whose watcher list was changed."

First observedv0.1.0Aug 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say non-destructive/idempotent; the description goes much further, disclosing that the API returns 204 regardless of prior state, that `changed` is null and must not be read as proof of prior subscription, that a 404 refers to an unknown user id rather than watch state, and the differing permission requirements for self vs. other. That is exactly the kind of trap-avoidance context annotations cannot carry.

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?

Front-loaded with the action, then a scoped usage sentence, then labeled Pitfalls and Cross-references sections that are dense with actionable content. Slightly verbose and repeats the watch-state point twice (once in the returns sentence, once under Pitfalls), but no sentence is 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?

For a two-parameter mutation with an output schema, the description covers permissions, what is and is not mutated, error semantics, and the verification path via get_work_package. There is nothing an agent needs to call this correctly that is missing.

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 both parameter descriptions already explain id sourcing and the 'me' restriction, so the schema does the work. The description adds no format or edge-case detail about the parameters themselves beyond that, so the baseline 3 applies.

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?

States a specific verb and resource: 'Unsubscribe a user from a work package's notifications.' It also differentiates from the sibling add_work_package_watcher ('the reverse') and from unrelated operations (unassign, project membership), so an agent can identify it without opening the schema.

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?

Gives the use case ('stop notifying someone who no longer needs the updates'), names the reverse tool, and points at get_work_package(include=['watchers']) to check current state before calling. It also states explicit exclusions — this does not unassign anyone or remove project membership — which is the when-not guidance most tools lack.

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

Deploy Server