Skip to main content
Glama

Update version

update_version

Update a version's name, dates, description, status, or sharing in OpenProject. Validate changes before applying, with support for moving sprint dates or closing releases.

Instructions

Change a version's name, dates, description, status or sharing.

Use it to move a sprint's dates, to close a finished release (status='closed'), or to widen sharing so a subproject can use the version. The change is validated through POST /versions/{id}/form first, so rejected values come back as violations naming the attribute.

Only the parameters you pass are sent, so concurrent edits to other fields survive. Versions carry no lockVersion upstream, so there is nothing to echo and no lock parameter here — a 409 would mean the resource itself changed, not a stale version.

Returns the updated version in the same shape as create_version.

Pitfalls: end_date writes the API's endDate — it lands, unlike in the old server. description REPLACES the stored text. Closing a version does not move or unassign its work packages; they keep pointing at it. The defining project cannot be changed — create a new version instead.

Cross-references: list_versions for ids and current values; delete_version when the version must really disappear; update_work_package(version=...) to move individual work packages between versions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoNew name. Omit to leave it alone.
statusNoopen, locked or closed. Closing a version keeps its work packages but stops new ones being assigned — it is the safe alternative to delete_version. Omit to leave the status alone.
sharingNonone, descendants, hierarchy, tree or system. Narrowing the sharing of a version other projects already use is rejected by the API. Omit to leave it alone.
end_dateNoNew finish date, ISO YYYY-MM-DD, written to the API's 'endDate'. Pass null to clear it. Omit the parameter to leave it untouched.__unchanged__
start_dateNoNew start date, ISO YYYY-MM-DD. Pass null to clear it. Omit the parameter entirely (the default) to leave it untouched.__unchanged__
version_idYesNumeric version id from list_versions or get_project_metadata(project_id=...).versions.
descriptionNoNew markdown description; REPLACES the existing text. Pass null or an empty string to clear it. Omit to leave it untouched.__unchanged__

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoVersion id — what update_version, delete_version and the work-package 'version' field consume.
nameNoVersion name, e.g. 'Sprint 12' or '2.1'.
sourceNo'sprint' when the row came from the backlogs sprints endpoint, 'version' otherwise. Sprints ARE versions upstream, so a row can be both and is then reported as 'sprint'.version
statusNoopen, locked or closed. Locked and closed versions reject new work package assignments.
projectNoThe project that DEFINES the version. A version shared from a parent project shows that parent here, not the project you asked about.
sharingNoHow far the version is shared: none, descendants, hierarchy, tree, system.
end_dateNoISO date (YYYY-MM-DD); the version's finish date.
created_atNoISO 8601 UTC timestamp.
start_dateNoISO date (YYYY-MM-DD).
updated_atNoISO 8601 UTC timestamp.
descriptionNoDescription as markdown (raw); html is dropped.
Behavior5/5

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

Discloses behavior well beyond annotations: validation via POST /versions/{id}/form returning violations, partial-update semantics with concurrent edit survival, absence of lockVersion, 409 meaning resource-level change, end_date→endDate mapping, description replacement, and the effect of closing. This is rich, trustworthy context.

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?

The description is long but well-structured into lead, use cases, validation/concurrency, pitfalls, and cross-references. Almost every sentence earns its place, though a few points (e.g., end_date/endDate mapping) slightly duplicate the schema's own param descriptions.

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?

Given 7 parameters, an output schema, and annotations, the description is fully complete: it explains behavior, side effects, validation failure mode, concurrency, pitfalls, and related tools. The return shape is adequately handled by referencing create_version's shape without over-explaining.

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?

Even though schema coverage is 100%, the description adds crucial semantics: only passed parameters are sent, end_date maps to API endDate, description REPLACES text, null clears values, and omitted parameters stay untouched. This complements the schema rather than repeating it.

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?

Opens with a specific verb and resource: “Change a version's name, dates, description, status or sharing.” It clearly distinguishes itself from related tools by naming concrete use cases and cross-referencing list_versions, delete_version, and update_work_package for different intents.

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?

Provides explicit when-to-use guidance: move sprint dates, close a release, widen sharing. It also states when NOT to use it (defining project cannot change—create a new version; delete_version when the version must disappear; update_work_package to move work packages), which is exemplary.

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