Skip to main content
Glama

Create version

create_version

Create a version (release, milestone, or sprint) in an OpenProject project to plan releases or start sprints before assigning work packages.

Instructions

Create a version (release, milestone or sprint) inside a project.

Use it to open a new sprint or plan a release before assigning work packages to it. The call goes through POST /versions/form first, so a duplicate name or an impossible date range comes back as violations naming the attribute instead of an opaque rejection.

Returns the created version {id, name, project, status, start_date, end_date, description, sharing, source, created_at, updated_at}. The id is what update_work_package(version=...) and update_version consume.

Pitfalls: end_date is the version's finish date and is written to the API's endDate field — passing a date here always lands (an older client dropped it silently). Creating versions needs the 'manage versions' permission in the project, so a 403 is about the account, not the payload. Versions are per project: sharing is the only way another project sees this one.

Cross-references: list_versions for what already exists (and for the ids); update_version to change dates or close it later; list_projects for the project id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesVersion name, e.g. 'Sprint 12' or 'Release 2.1'. Must be unique inside the defining project.
statusNoopen (default upstream), locked or closed. Locked and closed versions cannot receive new work packages, so create with 'open' unless you are recording history.
sharingNoWhich other projects may use this version: none (default), descendants, hierarchy, tree or system (the whole instance). Use 'descendants' for a release shared with subprojects.
end_dateNoISO date (YYYY-MM-DD) the version finishes — this is the version's due date, sent as the API's 'endDate'. Omit for none.
project_idYesNumeric id or identifier of the project that will DEFINE the version. Sharing decides which other projects can use it; the defining project cannot be changed afterwards.
start_dateNoISO date (YYYY-MM-DD) the version starts. Omit for none.
descriptionNoMarkdown description of the version's scope. Omit for none.

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?

The description discloses significant behavioral details beyond the annotations: POST /versions/form validation with 'violations' naming attributes, the returned object and id usage, the end_date-to-endDate mapping (and the older client dropping it silently), the 'manage versions' permission requirement, and the per-project sharing semantics. This is rich, non-obvious context.

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 with clear paragraphs: primary use, when-to-use, validation behavior, return value, pitfalls, and cross-references. Every sentence earns its place, and no information is wasted. It is appropriately sized for a tool with 7 parameters and subtle behavioral caveats.

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 the tool's complexity, the description is complete: it covers creation purpose, validation behavior, return value, permission requirements, pitfalls, and relationships to sibling tools. The output schema is also present, further reducing ambiguity. This is a comprehensive and self-sufficient description.

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?

The schema already covers all parameters with detailed descriptions (100% coverage), so the baseline is 3. The description adds extra meaning around key parameters: end_date 'always lands' and maps to the API's endDate, project_id is the defining project that cannot be changed afterwards, and the returned id is consumed by update_work_package(version=...) and update_version. These nuances go 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 'Create a version (release, milestone or sprint) inside a project,' which uses a specific verb and resource, and clearly distinguishes this tool from sibling tools like update_version, list_versions, and delete_version.

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 states when to use the tool ('Use it to open a new sprint or plan a release before assigning work packages to it') and provides cross-references to alternatives: list_versions for existing versions, update_version for changes, and list_projects for project id. This gives clear guidance on when to use this tool vs 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