bulk_create_work_packages
Creates multiple OpenProject work packages in one sequential call, returning per-item success or errors. Use it to batch project tasks in order instead of repeated single creates.
Instructions
Create multiple work packages in one call.
New items have no identifier field to set (unlike bulk_update_work_packages's
work_package_id); each result item is matched back to its input purely by index.
Each item in items must contain project, type, and subject. Optional fields per item:
description, version, target_versions (a list of version names/ids for OpenProject's
multi-version feature; cannot be combined with version on the same item), project_phase,
assignee, responsible, priority, category,
custom_fields, parent_work_package_id (or parent, an alias for the same field, matching
create_work_package's naming; do not specify both on the same item), start_date
(YYYY-MM-DD), due_date (YYYY-MM-DD), estimated_time, remaining_time, duration
(ISO8601 duration strings, e.g. 'PT8H' or 'P1D'). An item containing any other key is
rejected with an indexed validation error rather than silently dropping the unrecognized field.
due_date falling on a non-working day (e.g. a weekend) can be silently moved forward to the
next working day by OpenProject; compare the request and the returned item's
result.result.due_date if the exact calendar date matters. This server does not expose a
way to opt out of that shift (OpenProject's own ignoreNonWorkingDays flag is not a write
parameter here).
A rejected item's validation is not a tool error; inspect each item's success,
error, and nested result rather than the MCP error envelope.
select restricts each item's nested result to the given fields (e.g.
["ready", "work_package_id"]); an invalid name returns the allowed set.
These are write-result fields (work_package_id, ready, state, ...), not work
package fields: display_id and the rest come with result, the full
written work package. The index/success/error fields on each item are always
included regardless of select, so you can still tell which items succeeded;
listing them in select is accepted and changes nothing. For batches with many
items or long descriptions, set select proactively; an unconfirmed preview
echoes each item's full proposed payload, and an unbounded batch can exceed
the tool-result size limit and get redirected to a file.
A per-item timeout is reported as that item's failure and does not stop the loop. If this call is cancelled outright (e.g. the host cancels the request), items already created beforehand remain on the server; items not yet attempted are not created. No result summary is returned in that case (the call ends via cancellation, not a normal return); use list_work_packages/get_work_package afterward to determine what was actually written. This operation is not atomic; OpenProject CE has no batch/transaction endpoint.
Items are processed strictly sequentially in list order, and each result's index reflects that order; use this tool instead of parallel create_work_package/create_subtask calls whenever the relative order of a batch matters.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| select | No | Fields to return; a requested unset field comes back as null. Allowed: action, error, index, message, payload, project, ready, result, state, success, validation_errors, work_package_id. | |
| confirm | No | false: preview of every item, nothing changes. true: attempts every item; get the user's approval of the preview first. Failed items are reported per item; items already written are not undone. |