Skip to main content
Glama

Update work package

update_work_package

Change any writable field of an OpenProject work package — assignee, status, dates, parent, progress, or custom fields. Optimistic locking prevents overwriting concurrent edits.

Instructions

Change any writable field of a work package, with optimistic locking done properly.

Use it to assign or unassign, move a status forward, re-schedule, re-parent, set progress or write custom fields. Every convenience the old tooling spread across a dozen tools is a parameter here.

Returns the updated work package in full detail, including the new lock_version to use for a follow-up edit.

Pitfalls: omitted parameters are left alone, while passing null clears a field (assignee, responsible, version, parent, dates, description). A 409 error means somebody else changed the work package first — the error carries the fresh lock_version and the conflicting fields, so re-read, decide, and retry deliberately rather than blindly. Status changes are validated against the workflow, so an invalid transition lists the allowed targets.

Ids come from get_work_package / list_work_packages; status, priority, type and version values come from get_project_metadata.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesWork package id to change (the #1234 number).
dateNoMilestone date (YYYY-MM-DD); only valid on milestone types.__unchanged__
typeNoNew type as a name or numeric id. Cannot be cleared.
notifyNoSend OpenProject notification emails for this change.
statusNoNew status as a name or numeric id. Validated through the form endpoint, so an invalid workflow transition comes back listing the statuses that *are* reachable from the current one.
subjectNoNew title. Omit to leave unchanged; cannot be cleared.
versionNoNumeric version / sprint id; null removes it from the version.__unchanged__
assigneeNoNumeric user id to assign. Omit to leave unchanged; pass null (or 'none') to unassign — that sends a null href rather than a bogus user id.__unchanged__
due_dateNoISO date (YYYY-MM-DD); null clears it.__unchanged__
priorityNoNew priority as a name or numeric id.
parent_idNoRe-parent this work package under another id; null detaches it and makes it top level. This is the only hierarchy tool — there is no separate set/remove-parent tool.__unchanged__
start_dateNoISO date (YYYY-MM-DD); null clears it.__unchanged__
descriptionNoNew markdown body. Omit to leave unchanged; pass null to empty it. Replaces the whole description — read it with get_work_package first if you mean to append.__unchanged__
responsibleNoNumeric user id of the accountable person; null clears it.__unchanged__
lock_versionNoThe `lock_version` you read from get_work_package. Pass it and the write fails loudly (409) if somebody else edited the work package in the meantime. Omit it and the current version is fetched and echoed — still safe, just one more round trip and a slightly wider conflict window.
custom_fieldsNoCustom field writes keyed by wire key or display name, e.g. {'Severity': 'High'}. Unknown or non-writable keys fail with the valid keys listed. Only the keys you pass are touched.
estimated_hoursNoEstimate in hours as a decimal.
percentage_doneNoProgress 0-100.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoWork package id.
dateNoMilestone date (ISO YYYY-MM-DD); null for non-milestones.
typeNoWork package type.
notesNoDegradation notes for this result.
authorNoCreating user.
parentNoParent work package.
statusNoStatus.
projectNoOwning project.
subjectNoSubject line.
versionNoVersion / sprint.
assigneeNoAssigned user or group.
categoryNoCategory.
due_dateNoISO date (YYYY-MM-DD).
priorityNoPriority.
availableNoFeature availability for this WP: dev links, meetings, files.
created_atNoISO 8601 UTC timestamp.
display_idNoHuman-facing id as the instance renders it. Matches the numeric id unless the instance uses semantic identifiers (17.x, e.g. 'PROJ-42'); null when the instance predates it.
start_dateNoISO date (YYYY-MM-DD).
updated_atNoISO 8601 UTC timestamp.
descriptionNoDescription as markdown (raw); html is dropped.
responsibleNoAccountable user.
spent_hoursNoLogged time in hours.
lock_versionNoOptimistic-locking version; pass to update_work_package.
custom_fieldsNoAlways a list; empty when none are set.
project_phaseNoProject phase this work package sits in (16.1+, only when phases are active in the project and visible to this user); details via get_project_phase.
estimated_hoursNoEstimate in hours.
percentage_doneNoProgress, 0-100.
Behavior5/5

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

Beyond the annotations (readOnlyHint false, destructiveHint false), the description discloses optimistic locking, null-clears-field semantics, omitted-parameters-left-alone, workflow validation, and 409 conflict details. It also states the return includes the new lock_version, going well beyond what annotations provide.

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 structured into purpose, use cases, return value, pitfalls, and data sources. Every sentence carries useful information; the length is justified by 18 parameters and complex concurrency semantics.

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?

With a rich output schema and 18 parameters, the description covers all critical operational aspects: optimistic concurrency, null behavior, workflow validation, error handling, and source of identifiers/values. It is fully sufficient for an agent to invoke correctly.

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?

Schema coverage is 100%, but the description adds essential global semantics: omitted parameters are untouched while null clears fields, and it explains the lock_version conflict window and the parent_id uniqueness as the only hierarchy tool. This adds meaning 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 'Change any writable field of a work package' – a clear verb+resource statement. It then lists specific use cases (assign/unassign, status transitions, rescheduling) and explicitly contrasts with the old fragmented tooling, distinguishing it from siblings like create_work_package and delete_work_package.

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?

The description explicitly directs when to use this tool: 'Use it to assign or unassign, move a status forward, re-schedule, re-parent...' It also provides cross-references: IDs come from get_work_package/list_work_packages, and values from get_project_metadata. It explains the 409 conflict retry behavior and when to re-read, offering clear guidance versus alternatives.

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