OpenProject CE MCP Server

Overview Schema Source Related Servers Discussions Admin

Copy project

copy_project

Copy a project’s settings and optionally its work packages into a new project to start a release or engagement from a template without rebuilding members, versions, or categories.

Instructions

Copy a project — its settings, and optionally its work packages — into a new one.

Use it to spin a new engagement or release off a template project, which is the only way to reproduce a project's members, versions, categories and enabled modules in one call. The request goes through POST /projects/{id}/copy/form first, so a name that derives a taken identifier comes back as violations naming the attribute instead of a failed background job.

Copying is ASYNCHRONOUS: OpenProject queues a job and answers immediately. This tool therefore returns {scheduled: true, job_id, status, message, notes} and NEVER claims the copy exists — a large project takes minutes. Poll get_job_status(job_id=...) until status is 'success' (it then reports the new project) or 'failure'.

Pitfalls: only include_work_packages and notify are exposed; every other copy flag (members, versions, wiki, boards, file links) keeps this instance's own default, which the form fills in — so the copy can contain more than the two parameters suggest. A 403 means the account may not copy this project (it needs the 'copy project' permission on the template plus the right to create projects). Work packages come across with their relations, but time entries and comment histories do not.

Cross-references: get_job_status follows the job to completion; list_projects or get_project confirms the result; create_project makes an empty project instead; update_project renames the copy afterwards.

Input Schema

Name	Required	Description
`notify`	No	Send OpenProject notification emails for everything the copy creates. false (default) keeps a large copy quiet; the copy itself is identical.
`new_name`	Yes	Display name of the copy, e.g. 'Apollo migration (2027)'. OpenProject derives the copy's URL identifier from it; the derived value is reported by get_job_status once the job succeeds.
`id_or_identifier`	Yes	Numeric id or URL identifier of the project to copy (the TEMPLATE, not the copy). Both are accepted and come from list_projects or get_project.
`include_work_packages`	No	Copy the template's work packages too (default). false copies the project shell — members, versions, categories, wiki and the other settings the instance defaults to — without any tickets.

Output Schema

Name	Required	Description	Default
`notes`	No
`job_id`	No
`source`	Yes
`status`	No
`message`	No
`project`	No
`new_name`	Yes
`scheduled`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed22 schema fields changedv0.4.0Oct 24, 2026

removedOutput schema / description

Removed value: -"Outcome of ``copy_project`` — a *started* job, never a finished copy."

removedOutput schema / properties / job_id / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedOutput schema / properties / job_id / default
```
Removed value: -null
```

removedOutput schema / properties / job_id / description

Removed value: -"Background job id — pass it to get_job_status. Null when the instance reported none; 'notes' then says what to do instead."

addedOutput schema / properties / job_id / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / message / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedOutput schema / properties / message / default
```
Removed value: -null
```

removedOutput schema / properties / message / description

Removed value: -"Message the job reported, when it carried one."

addedOutput schema / properties / message / type
```
Added value: +[
+  "string",
+  "null"
+]
```
removedOutput schema / properties / new_name / description
```
Removed value: -"Name requested for the copy."
```

removedOutput schema / properties / notes / description

Removed value: -"What is still outstanding. Always says the copy has to be polled."

changedOutput schema / properties / project / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "description": "A reference to another resource. Canonical output shape.",
-    "properties": {
-      "id": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Resource id."
-      },
-      "name": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Human-readable name."
-      }
-    },
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "type": [
+          "integer",
+          "string",
+          "null"
+        ]
+      },
+      "name": {
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / project / default
```
Removed value: -null
```

removedOutput schema / properties / project / description

Removed value: -"The copy itself ({id, name}) — only populated on the rare instance that finishes the job before answering. Normally null: read it from get_job_status."

removedOutput schema / properties / scheduled / description

Removed value: -"True once OpenProject accepted the request. The copy itself runs in the background and is not finished when this is true."

removedOutput schema / properties / source / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "string"
-  }
-]

removedOutput schema / properties / source / description

Removed value: -"The project id or identifier that was copied."

addedOutput schema / properties / source / type

Added value: +[
+  "integer",
+  "string"
+]

removedOutput schema / properties / status / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedOutput schema / properties / status / default
```
Removed value: -null
```

removedOutput schema / properties / status / description

Removed value: -"Job state at the moment the copy was accepted, normally 'in_queue'. Null when the instance reported none."

addedOutput schema / properties / status / type
```
Added value: +[
+  "string",
+  "null"
+]
```

First observedv0.1.0Aug 12, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover only the read/write and idempotency profile; the description adds the crucial asynchronous behavior (queues a job, returns {scheduled, job_id, status, message, notes}), the polling contract, the fact it never claims the copy exists, the 403 permission cause, and that relations copy but time entries and comment histories do not. This is exactly the context annotations cannot carry.

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?

Front-loaded with the core action, then clearly segmented into async behavior, pitfalls, and cross-references. Slightly verbose in places (the 'spin a new engagement' framing, the repeated polling advice) but nearly every sentence adds an operational fact.

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?

Even though an output schema exists, the description explicitly describes the return shape and the polling loop, plus permission requirements and data-fidelity limits. Nothing an agent needs to invoke this correctly is missing.

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 baseline is 3, but the description adds real meaning: only include_work_packages and notify are exposed while other copy flags (members, versions, wiki, boards, file links) fall back to instance defaults, so the copy may contain more than the two booleans imply. The id_or_identifier 'template, not the copy' clarification is also reinforced.

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?

States a specific verb and resource ('Copy a project — its settings, and optionally its work packages — into a new one') and immediately differentiates it from sibling create_project later on. An agent can distinguish it from update_project/create_project without opening the schema.

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?

Gives the template/engagement scenario for when to use it, plus explicit alternatives: create_project 'makes an empty project instead', update_project 'renames the copy afterwards', get_job_status follows the job. Permission conditions for a 403 are also spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server