Skip to main content
Glama

Create project

create_project

Creates a new OpenProject workspace or subproject, validating input through the form endpoint first. Returns project details including ID and identifier for use in other tools.

Instructions

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

Use it for a new workspace or, with parent_id, for a subproject of an existing one. The call runs POST /projects/form before committing, so a taken identifier, an unusable parent or a bad status comes back as violations naming the attribute instead of an opaque failure — and the identifier OpenProject derives from the name is used verbatim on the commit.

Returns the created project: {id, identifier, name, active, public, parent, status_code, description, status_explanation, created_at, updated_at}. Keep the id — every other tool's project_id accepts it, as does the identifier.

Pitfalls: creating projects usually requires the 'create project' permission or admin rights, so a 403 here is about the account, not the payload. The new project starts with the instance's default modules and types enabled — check get_project_metadata(project_id=...) before creating work packages in it. Members are not copied from the parent; add them with create_membership (admin-gated: hidden unless the server sets OPENPROJECT_MCP_ADMIN_TOOLS=1).

Cross-references: list_projects finds the parent id; update_project changes any of these fields afterwards; get_project_metadata lists the types, versions and categories valid inside the result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDisplay name of the new project, e.g. 'Apollo migration'. Names need not be unique on the instance; the identifier is what must be.
publicNoTrue makes the project visible to every logged-in user without a membership. Omit to take the instance default (normally private).
parent_idNoNumeric id or identifier of the parent project, to create a subproject. Ids come from list_projects. Omit for a top-level project. Creating a subproject needs the 'add subprojects' permission on the parent.
identifierNoURL slug for /projects/<identifier>: lowercase letters, digits, '-' and '_' only, unique across the whole instance. Omit it and OpenProject derives one from the name — the derived value is in the result. A slug that is already taken comes back as a validation violation, not a surprise rename.
descriptionNoProject description in markdown. Omit to leave it empty.
status_codeNoInitial project status: on_track, at_risk, off_track, not_started, finished or discontinued. These codes are the only accepted values — a free-text status is rejected rather than silently dropped. Omit for no status.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoNumeric project id; accepted by every project_id parameter.
nameNoDisplay name.
activeNoFalse for archived projects (read-only in the UI).
parentNoParent project, when this is a subproject.
publicNoTrue when visible to users without a membership.
created_atNoISO 8601 UTC timestamp.
identifierNoURL slug from /projects/<identifier>; also accepted wherever an id is.
updated_atNoISO 8601 UTC timestamp.
descriptionNoDescription as markdown (raw); html is dropped.
status_codeNoProject status code, one of: on_track, at_risk, off_track, not_started, finished, discontinued. A code, never a translated label; null means no status has been set.
workspace_typeNoWorkspace kind: 'project', 'program' or 'portfolio'. Pre-17 instances only have 'project'; on 17.x project listings mix all three kinds, so check this before treating a row as a plain project.
status_explanationNoFree-text explanation of status_code, markdown (raw).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

The description discloses behaviors far beyond the annotations: it explains the pre-commit POST /projects/form validation producing violations, the verbatim use of the derived identifier, 403 meaning an account/permission issue rather than payload, the project inheriting instance defaults, and members not being copied. Annotations only provide basic hints (non-read-only, non-destructive), while the description carries the full behavioral disclosure and does so thoroughly. No contradiction.

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 logically structured: purpose, validation behavior, return format, pitfalls, and cross-references are in separate sections. Every sentence adds factual information, though some could be tightened (e.g., the duplicate permission notes). It's appropriately sized for a tool with this many caveats and a clear lead sentence.

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?

The description is complete for an agent to call the tool correctly: return fields are listed, permission pitfalls are explained, related tools are named with their purposes, and the validation semantics prevent surprises. With an output schema and rich annotations optionally present, the description still adds all the operational context an agent needs and leaves nothing essential unstated.

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?

Input schema coverage is 100%, so baseline is 3. The description adds cross-parameter meaning beyond the schema: the derived identifier when omitted, the uniqueness violation behavior, permission requirements for parent_id, and the strict enum acceptance for status_code. These contextual nuggets help an agent reason about parameter interactions, though the schema itself already documents each field well.

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 uses a specific verb and resource ('Create a project, validated through OpenProject's own form endpoint first') and immediately distinguishes creation of top-level vs subprojects via parent_id. It clearly positions the tool against siblings like list_projects, update_project, and create_membership, so an agent can tell them apart without opening schemas.

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?

It explicitly states when to use the tool: 'Use it for a new workspace or, with parent_id, for a subproject of an existing one.' It also provides cross-references and exclusions: list_projects finds the parent id, update_project changes fields afterwards, create_membership is for adding members, and get_project_metadata is the follow-up before creating work packages. This is clear guidance with alternatives.

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

Deploy Server

Other Tools