OpenProject CE MCP Server

Overview Schema Source Related Servers Discussions Admin

Update work package relation

update_work_package_relation

Idempotent

Change an existing work package relation's type, lag, or description to correct link types, adjust scheduling gaps, or explain connections; returns the updated relation.

Instructions

Change an existing relation's type, lag or description.

Use it to widen the gap between a predecessor and its successor, to correct a link that was created with the wrong type, or to explain why two work packages are connected. Returns the updated relation.

Pitfalls. At least one of type, lag or description must be given. Relations carry no lock version, so this is a plain overwrite with no conflict detection — a concurrent edit is silently replaced; re-read the relation if that matters. The two work packages cannot be changed here: delete the relation and create a new one instead. Raising the lag on a follows relation reschedules the successor, so dates can move.

Cross-references: create_work_package_relation makes one; delete_work_package_relation removes it; get_work_package(include=['relations']) lists the ids.

Input Schema

Name	Required	Description
`lag`	No	New lag in working days; valid only while the relation is 'follows' or 'precedes'. Omit to leave it untouched, pass 0 to remove an existing lag. When lag is given without type, the current type is read first and a lag on a non-scheduling relation is refused before any write.
`type`	No	New relation type. Omit to keep the current one. Switching to or from 'follows'/'precedes' changes whether the relation schedules dates.
`description`	No	New note for the relation. Omit to leave it untouched; pass an empty string to clear it.
`relation_id`	Yes	Id of the relation to change. It comes from create_work_package_relation or get_work_package(include=['relations']) — it is not a work package id.

Output Schema

Name	Required	Description	Default
`id`	No
`lag`	No
`type`	No
`description`	No
`reverse_type`	No
`to_work_package`	No
`from_work_package`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed27 schema fields changedv0.4.0Oct 24, 2026

removedOutput schema / description

Removed value: -"One work-package relation.\n\nThe two endpoints that produce relations — the ``relations`` include of\n``get_work_package`` and the relation write tools — return this same shape.\n``from_work_package``/``to_work_package`` are spelled out because the wire's\n``from``/``to`` read as prepositions rather than as the two ends of an edge."

removedOutput schema / properties / description / anyOf

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

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

removedOutput schema / properties / description / description

Removed value: -"Free-text note stored on the relation; null when unset."

addedOutput schema / properties / description / type
```
Added value: +[
+  "string",
+  "null"
+]
```

changedOutput schema / properties / from_work_package / 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 / from_work_package / default
```
Removed value: -null
```
removedOutput schema / properties / from_work_package / description
```
Removed value: -"Work package the relation starts at."
```

removedOutput schema / properties / id / anyOf

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

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

removedOutput schema / properties / id / description

Removed value: -"Relation id. Pass it to update_work_package_relation or delete_work_package_relation — it is not a work package id."

addedOutput schema / properties / id / type

Added value: +[
+  "integer",
+  "string",
+  "null"
+]

removedOutput schema / properties / lag / anyOf

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

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

removedOutput schema / properties / lag / description

Removed value: -"Working days kept between the predecessor and the successor. Only follows/precedes relations carry one; null everywhere else."

addedOutput schema / properties / lag / type

Added value: +[
+  "integer",
+  "null"
+]

removedOutput schema / properties / reverse_type / anyOf

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

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

removedOutput schema / properties / reverse_type / description

Removed value: -"The same relation read from the 'to' work package: 'follows' <-> 'precedes', 'blocks' <-> 'blocked', 'relates' <-> 'relates'."

addedOutput schema / properties / reverse_type / type
```
Added value: +[
+  "string",
+  "null"
+]
```

changedOutput schema / properties / to_work_package / 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 / to_work_package / default
```
Removed value: -null
```
removedOutput schema / properties / to_work_package / description
```
Removed value: -"Work package the relation points to."
```

removedOutput schema / properties / type / anyOf

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

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

removedOutput schema / properties / type / description

Removed value: -"Relation type as OpenProject stored it, read from the 'from' work package (e.g. 'follows' means 'from' is scheduled after 'to')."

addedOutput schema / properties / type / type
```
Added value: +[
+  "string",
+  "null"
+]
```

First observedv0.1.0Aug 12, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond annotations, it discloses important behavior: at least one field must be supplied, there is no lock version or conflict detection, concurrent edits are silently overwritten, and lag changes on follows relations can reschedule the successor. These are operationally significant details not captured by the 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?

The description is front-loaded with the core purpose and use cases, then uses a compact Pitfalls section for constraints and a Cross-references section for alternatives. Despite its length, each part adds useful guidance for correct invocation.

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 tool has annotations and an output schema, and the description covers the remaining operational risks: required-field behavior, overwrite semantics, scheduling side effects, and what cannot be changed. An agent has enough information to invoke it correctly and avoid common errors.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and already explains type, lag, description, and relation_id semantics. The description reinforces key constraints, especially that at least one of type/lag/description is required and that linked work packages cannot be changed here.

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 states a specific verb and resource: 'Change an existing relation's type, lag or description.' It also distinguishes this tool from siblings by naming create, delete, and get-with-relations alternatives.

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?

It gives concrete use cases: widening predecessor/successor gaps, correcting wrong link types, and explaining connections. It also names the alternatives explicitly and explains when to use delete+create instead of updating linked work packages.

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

Deploy Server