Skip to main content
Glama

Create work package

create_work_package

Create tasks, bugs, subtasks, or milestones in OpenProject with pre-flight validation. Invalid inputs return structured errors listing allowed values before anything is saved.

Instructions

Create a work package, validated through OpenProject's own form endpoint first.

Use it for new tasks, bugs, subtasks (parent_id) and milestones (date). The form pre-flight is what makes failures useful: an invalid status, a missing required custom field or a type the project does not enable comes back as structured violations with the allowed values, before anything is written.

Returns the created work package in full detail, including its new id, lock_version and resolved custom fields.

Pitfalls: type, status and priority take names or ids, but versions, assignees and parents need numeric ids. Milestone types reject start_date/due_date — use date. Custom fields must exist on the project/type schema; check get_work_package_schema when unsure.

To change it afterwards use update_work_package; to attach a file to an existing work package use upload_attachment.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoThe single ISO date of a **milestone**. Milestones carry `date` instead of start_date/due_date; passing both shapes is rejected locally.
typeYesWork package type as a **name or numeric id** ('Task', 'Bug', 'Milestone', or 7). Names resolve against this instance's types; an unknown or ambiguous name fails with the valid values listed.
notifyNoSend OpenProject notification emails for this creation.
statusNoStatus name or numeric id. Omit to take the type's default status — do not guess an id.
projectYesNumeric project id or project identifier (URL slug). Both come from list_projects.
subjectYesThe title. Required and must not be blank.
versionNoNumeric version / sprint id; from get_project_metadata.
assigneeNoNumeric user id to assign. 'me' is not accepted in writes — call get_instance_info for the current user's id.
due_dateNoISO date (YYYY-MM-DD). Not valid on milestone types.
priorityNoPriority name or numeric id ('High', 'Normal', or 8). Omit for the instance default; priority ids differ per instance.
parent_idNoCreate this as a child of an existing work package id.
start_dateNoISO date (YYYY-MM-DD). Not valid on milestone types.
descriptionNoBody text in markdown. Omit for an empty description.
responsibleNoNumeric user id of the accountable person.
custom_fieldsNoCustom field writes keyed by wire key or display name: {'customField12': 'High'} or {'Severity': 'High'}. List/user/version fields accept option ids or option names. Unknown or ambiguous keys fail with the valid keys listed — nothing is ever silently dropped. get_work_package_schema shows what this project and type accept.
estimated_hoursNoEstimate in hours as a decimal (7.5 = seven and a half).
attachment_pathsNoLocal file paths to attach. Files upload uncontainered first and are claimed by the new work package, which is the flow that works even when the author lacks edit permission. Only usable when the server shares a filesystem with you (stdio transport).

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, etc.), the description discloses the form-validation pre-flight, structured error responses with allowed values, return details (id, lock_version, resolved custom fields), and pitfalls around parameter types (names vs numeric ids) and milestone date restrictions. This is rich, non-obvious behavioral 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 tightly organized: purpose, use cases, validation behavior, return value, pitfalls, and alternatives. Every sentence provides actionable information. It is longer than average, but the density of useful detail justifies the length.

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 (17 parameters, output schema present, rich annotations), the description covers everything an agent needs: what it does, how validation works, what is returned, key parameter restrictions, and where to get more schema details. It also names sibling tools for follow-up actions, making the description contextually complete.

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%, so the baseline is 3. The description adds value through synthesized pitfalls: 'type, status and priority take names or ids, but versions, assignees and parents need numeric ids' and 'Milestone types reject start_date/due_date — use date.' These cross-cutting rules go beyond individual schema descriptions but are not huge; hence 4.

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 work package' — a specific verb and resource. It further clarifies scope by listing use cases: new tasks, bugs, subtasks (parent_id), and milestones (date). It distinguishes from siblings by explicitly naming update_work_package and upload_attachment for post-creation actions.

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 says 'Use it for new tasks, bugs, subtasks...' and gives alternatives: 'To change it afterwards use update_work_package; to attach a file to an existing work package use upload_attachment.' It also directs users to get_work_package_schema when unsure about custom fields, providing clear when-to-use and when-not-to-use guidance.

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